大家好，今天来为大家解答交易平台的架构这个问题的一些问题点，包括BtB业务架构的方法论和那些坑也一样很多人还不知道，因此呢，今天就来为大家分析分析，现在让我们一起来看看吧！如果解决了您的问题，还望您关注下本站哦，谢谢~

本文目录

1. 碳交易的总体架构
2. CS架构指什么
3. BtB业务架构的方法论和那些坑

一、碳交易的总体架构

总体而言，碳交易市场(见图1)可以简单地分为配额交易市场和自愿交易市场。配额交易市场为那些有温室气体排放上限的国家或企业提供碳交易平台，以满足其减排；自愿交易市场则是从其他目标出发(如企业社会责任、品牌建设、社会效益等)，自愿进行碳交易以实现其目标。

配额碳交易(见图2)可以分成两大类，一是基于配额的交易，买家在“总量管制与交易制度”体制下购买由管理者制定、分配(或拍卖)的减排配额，譬如《京都议定书》下的分配数量单位(AAUs)和欧盟排放交易体系(EU—ETS)下的欧盟配额(EUAs)；二是基于项目的交易，买主向可证实减低温室气体排放的项目购买减排额，最典型的此类交易为清洁发展机制(CDM)以及联合履行机制(JI)下分别产生核证减排量(CERs)和减排单位(ERUs)。

欧盟碳排放配额简单地说就是欧盟国家的许可碳排放量。欧盟所有成员国都制定了国家分配方案(NAP)，明确规定成员国每年的二氧化碳许可排放量(与《京都议定书》规定的减排标准相一致)，各国政府根据本国的总排放量向各企业分发碳排放配额。如果企业在一定期限内没有使用完碳排放配额，则可以出售；一旦企业的排放量超出分配的配额，就必须从没有用完配额的企业手中购买配额。

《京都议定书》的减排目标规定欧盟国家在2008—2012年平均比1990年排放水平削减8%，由于欧盟各成员国的经济和减排成本存在差异，为降低各国减排成本，欧盟于2003年10月25日提出建立欧盟排放贸易体系(EU—ETS)，该体系于2005年1月成立并运行，成为全球最大的多国家、多领域温室气体排放权交易体系。该体系的核心部分就是碳排放配额的交易。

欧盟排放贸易体系共包括约12000家大型企业，主要分布在能源密集度较高的重化工行业，包括能源、采矿、有色金属制造、水泥、石灰石、玻璃、陶瓷、制浆造纸等。航空业可能在2011年加入到这个体系中。

《联合国气候变化框架公约》(UNFC—CC)附件1缔约方国家(发达国家)之间协商确定排放配额(AAU)。这些国家根据各自的减排承诺被分配各自的排放上限，并根据本国实际的温室气体排放量，对超出其排放配额的部分或者剩余的部分，通过国际市场购买或者出售。

协商确定的排放配额只分配给附件1缔约方国家(发达国家)，因此很多东欧国家特别是俄罗斯、乌克兰、罗马尼亚等近年来由于制造业的衰退，成为排放配额市场的净出口国与最大受益国。东欧国家的排放配额盈余被称为“热空气”，由于这些“热空气”并非来自节能与能效提高而是来自产业缩水，所以大部分国家不愿意购买这些“热空气”，因为花钱购买这些配额似乎并不具有减排意义。

核证减排量(CER)，指的是附件1缔约方国家(发达国家)以提供资金和技术的方式，与非附件1国家(发展中国家)开展项目级合作(通过清洁发展机制)，项目所实现的核证减排量可经过碳交易市场用于附件1国家完成《京都议定书》减排目标的承诺。核证减排量是碳交易配额市场中最重要的基于项目的可交易碳汇。

指联合履行允许附件1国家通过投资项目的方式从同属于附件1的另外一个国家获得排放减量单位(ERU)。附件1国家在2000年1月1日之后开始的项目可以申请成为联合履行机制项目，但是联合履行机制产生的排放减量额只在2008年1月1日之后开始签发，因此联合履行机制比起清洁发展机制，发展相对不够充分。

自愿减排交易市场(见图3)早在强制性减排市场建立之前就已经存在，由于其不依赖法律进行强制性减排，因此其中的大部分交易也不需要对获得的减排量进行统一的认证与核查。虽然自愿减排市场缺乏统一管理，但是机制灵活，从申请、审核、交易到完成所需时间相对更短，价格也较低，主要被用于企业的市场营销、企业社会责任、品牌建设等。虽然目前该市场碳交易额所占的比例很小，不过潜力巨大。

从总体来讲，自愿市场分为碳汇标准与无碳标准交易两种。自愿市场碳汇交易的配额部分，主要的产品有芝加哥气候交易所(CCX)开发的CFI(碳金融工具)。自愿市场碳汇交易基于项目部分，内容比较丰富，近年来不断有新的计划和系统出现，主要包括自愿减排量(VER)的交易。同时很多非政府组织从环境保护与气候变化的角度出发，开发了很多自愿减排碳交易产品，比如农林减排体系(VIVO)计划，主要关注在发展中国家造林与环境保护项目；气候、社区和生物多样性联盟(CCBA)开发的项目设计标准(CCB)，以及由气候集团、世界经济论坛和国际碳交易联合会(IETA)联合开发的温室气体自愿减量认证标准(VCS)也具有类似性。至于自愿市场的无碳标准，则是在《无碳议定书》的框架下发展的一套相对独立的四步骤碳抵消方案(评估碳排放、自我减排、通过能源与环境项目抵消碳排放、第三方认证)，实现无碳目标。

二、CS架构指什么

1、服务器-客户机，即Client-Server(C/S)结构。C/S结构通常采取两层结构。服务器负责数据的管理，客户机负责完成与用户的交互任务。

2、客户机通过局域网与服务器相连，接受用户的请求，并通过网络向服务器提出请求，对数据库进行操作。服务器接受客户机的请求，将数据提交给客户机，客户机将数据进行计算并将结果呈现给用户。

3、两层结构由两部分构成:前端是客户机，主要完成用户界面显示，接受数据输入，校验数据有效性，向后台数据库发请求，接受返回结果，处理应用逻辑;后端是服务器，运行DBMS，提供数据库的查询和管理。

4、两层结构存在一些不足:主要表现在:系统的可伸缩性差;难以和其它系统进行互操作;难以支持多个异构数据库;客户端程序和服务器端DBMS交互频繁，网络通讯量大;所有客户机都需要安装、配置数据库客户端软件，这是一件十分庞杂的工作，等。

5、基于二层结构的以上不足，三层结构伴随着中间件技术的成熟而兴起。其核心概念是利用中间件将应用分为表示层、业务逻辑层和数据存储层三个不同的处理层次。

三、BtB业务架构的方法论和那些坑

互联网应用的根本目标在于提高效率，现在市场上几乎所有的应用都有这个特点，实现这个目标是通过两个途径做到的，其一是网络协同，其二是数据智能网络协同在实现层面需要各个角色在恰当的时间点作出恰当的操作，无论网络有都么智能，它在BtB领域总是需要具体的人来作出操作反馈的，所以信息流在线下线上的交互流转是我们在设计系统的时候需要充分考虑的一点，事实上简单的把需求方的线下业务搬到线上很多情况下不但不能提高效率，反而会发生负的外部效应

至于数据智能，绝大部分客户其实并不满足数据采集、数据清洗和数据分析的条件，最大程度上只能做到一些自动化统计功能

在实际业务中，我们会涉及到生态、平台这一类的说法

我自己的感受是90%以上关于上述课题的说法仅仅是扯淡而已。首先来看生态，比如一片草原，无论面积多么辽阔如果只有一种花草它是经不了风霜的，而生态的第一个属性就是反脆弱性，反脆弱性决定了只有异质物种才能组成生态，所以滴滴体量再大始终成不了阿里

再来看平台，某些客户会说我要做某个行业的平台，我想成为某个垂直领域的阿里。平台的本质含义是去中介化或者再中介化，然而中介这个交易链路在整个贸易历史上从商品经济诞生的那一天开始就有了，中介能够给交易环节赋能，能够为商品赋予独特的价值，这是理解中介的立足点，任何只看到中介成本而没有分析中介价值的平台都是耍流氓，大幅度低估了传统供应链渠道的价值以及新模式推广的难度

侧重于站在产品经理的角度描述BtB模式电商领域，在业务架构阶段可采用的一些方法和需要注意的细节，并会为此列出若干实例

本文档所述的BtB包括 BtBtB和 BtB2C模式，也会涉及到 StBtC模式

从逻辑上完整的描述从业务映射到系统的过程

目标在于为项目实操开发提炼出一套切实可行可落地的工作方法，能够绕开上述模式电商领域建设中一些坑

有些是现在写的，比较口语化，有些是摘抄我以前写的博客的，比较书面化

B端客户决策维度多，达成交易的最低要求高，但流程标准化，输出可靠性高；而C端客户的决策维度少，达成交易的最低要求低，但流程不标准，输出可靠性低。这是tB和tC用户属性的核心区别

正如上述用户属性说明，tB业务用户决策的维度多，流程长，直接从终端对接终端的交易效率太低，成本太高，所以就在供应链上产生了的很多"客户-供应商"关系链条，把这些因素降维成生意与生意之间的信任关系，虽然流程变长了，但实际决策效率却变高了。我们可以说，各种供应商实现了为整个交易链条赋能的功能

①对项目所处的行业，其中的全体参与者进行分类分析和研究，搞清楚哪些人在什么条件上有价值，哪些人在市场条件下没有价值。如果要替代掉供应链上的环节，当然是从最没有价值的环节入手，提供给最有话语权的用户看重价值的其他环节。分析的五个维度：

②为这个产业链提供某些原本不存在的价值，有效提升整个产业链的效率

完整的tB电商系统本质上就是一个信息化供应链，有完整的传统供应链内容，同时也有具备电商特色的功能，比如促活拉新和内容模块等

好产品的价值=（新体验-旧体验）-替换成本＞0这个公式我记得是梁宁提出来的

将业务单元高度抽象，每一个业务都划分为类和实例，利于后期修改以下将我认为需要注意的点提出来捋一次

这是个相对的概念，注意这个概念的主语更容易识别用户的真实意图

现在很多电商平台都以SPU为基本展示单位，但是在初期还是建议以SKU为基本展示单位，在视觉效果上显得商品比较丰富

可以大致分为前台展示类目和后台管理类目，两者之间需要对应一个松耦合关系，前台展示类目最好考虑周全一点，方便运营在做活动的时候随时调整

关键是拆单的逻辑，拆单之后原订单会生成多个子订单，此时原订单和子订单的状态表述需要根据具体业务去协调

订单中心拆单的逻辑和WMS中的分仓是紧耦合关系

多数都是调用第三方支付的接口，没什么好说的，需要注意的是落实到具体的B端公司，几乎每一个公司的财务制度都是不同的，那么怎么和客户的财务系统对接才是最大的工作量

调度层相当于订单的分配中心，将订单转化成发货单，按照调度规则决定哪些SKU由哪个仓库发货，发货仓的优先级设定

敲黑板，调度库存全部都是实物库存

解决供应链路中存在的反应速度和敏捷性的矛盾

自上而下：从销售到调度再到仓库

自下而上：主要是入库问题，采购入库、退货入库、调拨入库

销售订单、售后退货、预售、盘盈盘亏、仓间调拨、采购

可销售库存、锁定库存、已销售库存、活动库存、预售库存，预售的订单需要备货之后再推送到调度层

促销的功能大致可以分为两大类：拉新和促活无论哪一类总结为三个字，坑很多

尤其是逆向流程，一不小心就会留下漏洞，例如在平台满额减的情况下，涉及到退货，退款的额度就是个很大的问题了

内容管理系统，主要目标是页面动态配置模块化、组件化、乐高化

①采购入库，很可能是批次入库的，那么在做库存同步的时候，自下而上库存数据推送就需要分批次了

②多数客户的货号都使用条形码，但是少数客户会有自己的货号编码规则，这样采购入库的时候就会多一道贴码的工序

包括WMS、TMS和 OMS，主要功能是将订单转化为拣货单、发货单、入库单

等，以及分仓、分区域，并做仓位管理，生成拣货路线，根据拣货路线生成拣货波次，太复杂了，都可以写一本书，在此略过不提

大部分项目都会直接对接快递100,可是要明白一点，快递信息有两个层面的含义，一是反馈实时空间位移距离，二是缓解买家在等待到货这个过程中的焦虑，所以真正要设计一套完成的物流反馈信息还是很有难度的

记录用户行为，分析规避可能产生的违法行为，比如诈骗、利用系统漏洞刷单刷钱

设计整套电商系统需要遵循一个铁律：单据驱动数据

服务于BtB模式下的互联网产品首先是受客户的具体业务约束的，这一点有别于纯粹 2C的产品有很大发挥空间

一般情况下在MVP版本，电子商城或者整个电商系统就是为客户的实体业务做素描，在还原度达到80%以上的基础上再求创新

本质上这是一种受约束的小范围小粒度的创新

作为BtB领域的业务架构师，岗位职责就是完成从业务到系统的映射关系，概念上产品开发方法是这样的：

①几乎所有的互联网产品都起源于一个想法，有逼格的人把它叫做 IDEA

②尽快完成这个想法涉及到业务的闭环（MVP），包装成产品，投入市场

③全方位采集用户在使用过程中的数据，分析之后作为迭代的依据和验证标准

①要注意一点，系统活动≤业务活动，很多业务需求考虑成本和效率并不需要在系统层面去实现

②整个过程就类似于一个反向的涟漪，从外圈向内圈蔓延，这也是一个抽丝剥茧的过程

问怎么做的时候更要问为什么这么做，同样一个问题对于不同岗位的意义都是不一样的，360°的调研才能真正理解一个问题

提醒一点，不要迷信市调。一方面市调的样本肯定是有限的，有限的样本不一定能够反映市场的特征；第二方面，被调查的对象能够告诉你的永远都是已经发生过的事，而我们通常想做的产品都是面向今后的市场，昔日往事可以借鉴，要是用来指导将来就有的你好看了

业务调研完成后，最好输出一张服务蓝图，将客户所有与本项目有关的业务全部列出来，类似这样的东西：

最好是懂技术，你会发现事半功倍，基本思路就是讲调研所得转化为系统实现，输出业务事件清单和业务用例（BUC）

业务事件清单列明了所有干系人和相邻系统与本产品之间的互动，罗列了产品需要输入和输出的各种数据流，定义了数据流的类和属性，通过数据流的类和属性计算出功能点，用来估算工作量，估算工作量的公式：

工作量（人月）=（功能点数量÷150）×功能点数量的 0.4次方

通过对业务用例的解读，得到产品用例（PUC），现在可以根据产品用例来建模了，这时候曾经抽象的蓝图式的产品概念开始具象化，开始向可分解的工作流靠拢

需求并更是再正常不过的了，在实际操作中其实并没有一招制敌的方法，强行安利一种的话一般是这么干的：

①为每一个需求表明分值，表格如下

满意度从1到 5递增，愤怒值从 5到 1递减

③分别计算出满意度平均值和愤怒值平均数

④两者相乘，乘积就是该需求的总体得分，接下来让客户自己选吧

①通常情况下，客户指定和我方对接的负责人一般都是中层管理者，并没有最终决策权，对跨部门的业务了解程度并不深刻

②通常情况下，被指定和我方对接的负责人并不需要为项目的成败负担直接责任，权责也不是很明确

③在业务之外，还需要注意人事利益关系，这一点对项目能否顺利准时验收交付是很重要的。

④牢记一点，客户并不一定就是用户，客户需求是大于用户需求的，甚至于是冲突的，两者之间的关系分寸需要认证对待

关于交易平台的架构，BtB业务架构的方法论和那些坑的介绍到此结束，希望对大家有所帮助。