关于业务平台架构的思考

业务平台是连接业务战略与技术实现的桥梁。好的业务平台架构，不仅要沉淀可复用的基础设施以降低成本，更要通过开放的架构能力支持业务的快速创新与差异化经营。本文从"业务是什么"这一基本问题出发，逐步展开对业务平台架构定位、能力建模、域划分以及架构构建方法的系统性思考。

为了让抽象的方法论有具体的着力点，本文以电商交易平台作为贯穿全文的案例——它同时服务淘宝、天猫、1688 等多条业务线，是业务平台架构问题最典型的缩影。

全文分为四个部分递进展开：第一~~三章回答"业务平台是什么、解决什么问题"（定义与定位），第四~~七章回答"用什么方法论来思考"（模型、域、能力的分析框架），第八~~九章回答"具体怎么设计"（商业能力的划分与分层），第十~~十三章回答"落地时会遇到什么"（反模式、组织关系、构建方法和演进路径）。

一、从我们最熟悉的说起——业务是什么？

不同来源对"业务"有着不同层次的解读：

职业上的事务，统称为「业务」——辞海
"业务"更白话一些来说，就是各行业中需要处理的事务，但通常偏向指销售的事务，因为任何公司单位最终仍然是以销售产品、销售服务、销售技术等等为主。"业务"最终的目的是"售出产品，换取利润"。——百度
"Anything that relates to organizing the exchange of goods and services by a business, a governmental institution, or an agency."——OpenGroup TOGAF Business Architecture

业务的定义

业务：企业接受客户订购，并将商品或服务交付给客户的一系列活动的总和，称之为一个业务。

业务的基本特征是产品+组织。当产品交付给客户时，面向不同客户、市场、行业，如何解决业务的差异性？答案是业务身份。

业务身份是现实业务在系统中给予的唯一编码标识，是基于"业务"差异性划分而形成的系统 ID。业务身份的本质不是为了区分逻辑判断，而是区分需求来源以及规则的适用范围。因此，业务身份应该有全局的一致性。

案例：在电商交易平台中，淘宝 C2C、天猫 B2C、1688 B2B 就是三个不同的业务身份。同样是"下单-支付-履约"的交易流程，但淘宝允许议价、天猫价格固定、1688 支持批量采购和账期——这些差异不是通过 if/else 硬编码区分的，而是通过业务身份关联到不同的规则集。当新业务线（比如跨境电商）接入时，分配新的业务身份，挂载对应的规则集，而不需要修改核心交易流程。

二、业务平台架构的定位与价值

业务平台要解决什么问题？

从业务内部看和从全局看，业务平台面对两组不同但相关的诉求：

视角	维度	目标
业务内部	创新	不断适应市场的业务策略
	低成本	实施成本低
	快速响应	能快速推进，快速试错
	外部资源	易于获得生态内足够的外部资源，如流量、供给、渠道
全局	基础强大	有强大的基础平台支撑，通用能力得到保证
	组装灵活	可以快速选择部分能力，构建适合自身需要的支撑体系
	易于变化	变化牵涉面小，可以快速定制
	自主投入	不受基础平台资源瓶颈限制

从技术与业务两个角度看，需要的能力

功能丰富：靠积累
易于复用：粒度合适，易于集成（技术兼容）
开放定制：平台开放（架构开放），运行解耦（部署灵活）、研发过程解耦
信息共享：概念一致、场景链接
沟通顺畅：共同的术语、对业务整体的一致认识

业务平台的核心价值

降低成本：通过沉淀可复用的软件基础设施
支持创新：通过提供开放的基础架构能力，支持创新和差异化经营
全局管控：通过管理基础数据和基本流程节点，提供全局管控的手段和稳定性保障

案例：电商交易平台的价值体现——淘宝、天猫、1688 共享同一套交易引擎、支付系统、库存服务。如果每条业务线各建一套，三套系统的开发和维护成本是 3x；共享平台后，核心能力的成本降为 1x + 差异化定制的增量成本。同时，平台统一管理交易安全规则，一次升级全局生效。

被复用或信息共享的前提

能够被复用或信息共享需要满足以下前提：

核心管理对象的一致性
- 概念一致：对象+关系
- 数据描述一致：主数据
存在一定层次的流程一致性
- 关键活动
- 基本规则

软件复用的四种形式

复用形式	说明	案例
功能复用	一段功能被完整使用	淘宝和天猫共用同一个"创建订单"服务
接口复用	输入输出定义复用，实现逻辑重写	"计算运费"接口定义统一，但快递和物流的计算逻辑不同
流程复用	一段控制结构被复用，控制逻辑加上节点	"下单→支付→发货→确认收货"流程骨架复用，各业务线在节点上扩展
规则复用	一段判断逻辑被复用	"库存扣减规则"在所有业务线通用

复用的前提是业务实质的相似性。如果管理的核心对象存在较大差异，绝大部分情况下，以上复用都没可能。

但满足复用前提并不意味着应该立即平台化——过早的抽象同样有害。复用是一种结果而非目标，具体的时机判断见第十章"反模式一：过度平台化"。

业务平台的能力取决于什么？

是否存在基础的具有共性的关键业务环节
是否存在需要全局共享的关键资源
是否存在需要广泛连接的关键应用
是否存在需要大范围执行的管控规则
是否需要稳定性 SLA

三、业务架构的现状与挑战

通常，企业架构包括业务架构、技术架构、应用架构、数据/信息架构，而业务平台最薄弱的环节往往在于业务架构：

已经形成框架，但缺乏对关键概念的确切定义
已经形成平台，但缺乏长期演进的规划指引
已经形成对业务的基础性支撑，但基础能力没有明确的定义
平台团队缺乏对业务的结构化思考框架指引，容易造成团队能力的瓶颈

因此，我们首先需要健全业务架构体系。业务架构体系的构建关键在于先要建立业务视角。

什么是业务视角？

用业务发生的方式描述业务：围绕能力、流程与场景描述
将业务现象背后的逻辑进行结构化呈现
强调结果而非方法实现，屏蔽技术细节

案例：当我们说"交易平台支持担保交易"时，这是业务视角的描述——它说的是平台具备什么能力。而"通过 RPC 调用支付中心的 escrow 接口实现资金冻结"是技术视角。业务架构的文档中应该出现前者，而非后者。

如何建立业务视角？

首先要明确业务目标，理解业务含义，知道结构划分的依据
要建立端到端的全流程视角，业务需求能够对应到系统功能
在业务沟通中，统一使用达成共识的业务语言而非技术术语
系统被业务感知的部分要有明确的业务语义以及清晰的边界

业务平台架构的层次结构

业务平台架构是一个以流程为基础，以能力为表达的层次结构：

层次	目标	案例
第一层	明确语义和范围	"交易"的边界是什么？从下单到确认收货，还是包含售后？
第二层	构建完备、正交的业务模型	交易域、商品域、支付域、物流域的边界互不重叠
第三层	与交付形态相结合，提供服务 SLA	交易核心链路 99.99% 可用，营销活动 99.9% 可用

无论从能力角度，还是从流程角度，都是对企业行为的一种描述方式。我们既可以通过满足的客户需求出发，构建能力的集合，也可以根据流程到企业能力的对应，建立起整体的能力框架或过程框架。

四、业务架构模型分析

业界对业务架构的描述方式有多种参考模型：

模型	来源
Business Process	TMF、APQC
Business Capability	Open Group、Gartner
Value Stream	Open Group
Business Service	FEA

描述业务的三个视角

Business Capability（What）：业务为实现特定目的或结果而可能拥有或交互的特定能力或产能

A particular ability or capacity that a business may process or exchange to achieve a specific purpose.
Business Process（How）：一组有逻辑行为的结构化活动或任务，产生特定的结果、服务或产品

A set of structured activities or tasks with logical behaviors that produce a specific outcome, service or product.
Business Value Stream（Why）：表示一组端到端增值活动集合，这些活动为客户、干系人或者最终用户获得一个总体结果

A sequence of activities an enterprise undertakes to deliver on a customer request.

案例对照：以电商交易为例——

视角	描述	交易平台示例
Capability（What）	平台具备什么能力	"担保交易能力"、"分期支付能力"
Process（How）	业务怎么执行	"下单→锁库存→支付→扣库存→发货→确认收货"
Value Stream（Why）	为客户创造什么价值	"买家安全便捷地完成商品购买"

参考模型的共性

分析前述参考模型可以看到：

顶层视图一致：不论哪种描述方式，都是先从企业的管理范围做大的划分——基于价值链的分析形成顶级视图，以是否直接服务客户为基准划分不同分类
内容逻辑趋同：大多讨论都涉及组织、能力、过程的关系
目标一致：虽然在不同的时期、不同的视角强调的重点不同，但都是希望建立更易于为业务理解的视图，并成为构建 IT 系统的桥梁

五、关于域（Domain）的思考

域是一个广泛被使用的词，但定义也很宽泛。领域建模这个词很熟悉，但具体"领域"是什么，在实践中并没有可以判定的简单标准。域常常被理解为不同的场景：功能域、过程域、数据域。

如果从 OO（面向对象）的核心思想出发，则可以将域做一个统一认知：

功能是对象行为的外部表现，但作为域的聚合依据是对象
对象的行为和数据是不可分开的，过程是对象行为的执行过程

基于以上认知，域的概念可以统一为**「信息域」**——数据是信息的载体，信息是对数据的语义解释。因此，领域建模就是找出问题范围内的对象及其关系，根据对象间关系的紧密程度，来确定是否属于一个域。

案例：电商平台的域划分——

域	核心对象	为什么是一个域
商品域	商品、SKU、类目、属性	这些对象之间高度耦合，SKU 必须属于商品，属性必须挂在类目下
交易域	订单、订单项、交易状态	订单和订单项不可分割，交易状态是订单的核心行为
支付域	支付单、退款单、支付渠道	支付有独立的生命周期，与交易解耦（一笔交易可以多次支付）
物流域	物流单、运单、物流轨迹	物流有独立的时间线和状态机，与交易异步运作
用户域	买家、卖家、账户	用户身份跨所有业务线共享

为什么支付和交易是两个域而非一个？因为支付单有独立于订单的生命周期——订单取消后支付单可能仍在退款中，一笔订单可能对应多笔支付单（拆单支付）。对象间关系的紧密程度是判定域边界的核心依据。

六、能力的语义分析——5W1H 的逻辑

对能力进行语义分析，可以借助经典的 5W1H 框架：

维度	关注点	层次
Why	价值	高层次
What	目标	高层次
When	时间	细节层次
Where	地点	细节层次
Who	参与人	细节层次
How	方式方法	细节层次

当我们在较高层次谈能力，往往是在谈 Why 和 What；在较低或细节的层次谈能力，则往往强调的是 3W1H（When、Where、Who、How）——即做的程度和特性。

能力的两种描述形式

能力的描述通常有两种形式：

形式一：按照目标描述——做什么以及达到的目标。

形式二：按照特性描述——特性往往体现为两类：

对象属性值的组合：值的组合往往体现为场景。例如"担保交易"是一个能力描述，"担保"本身是交易的分类特性，描述的是交易具有的特点。
过程执行的非功能特性：如时间、空间等。例如"秒杀"描述的是交易的时间特性；"店铺红包"描述的是红包使用的范围（空间特性）。

能力与场景的结合

能力的特性描述实际是场景切分的方式。一旦进入场景，就是离散的结构；而按照流程的能力划分方式，则可以是逐步细化的方式，会形成树状的结构。

如果我们把二者结合并加以规范，就能形成既满足 MECE（Mutually Exclusive, Collectively Exhaustive）原则，又能把两种特点有效体现的描述方式：

按照端到端流程完成初始能力描述
找到流程的各个环节，分解成不同的能力
在流程各个环节里，找出关键参数，描述业务的适应能力
找出关键的非功能性的特性
把流程各个环节较为固定的组合找出来

七、能力、流程、域的关系

能力分析 vs 流程分析

能力：要达到一个目的，得到一个结果。如果是服务于客户，从客户的角度看，就是"我"帮客户完成了一件什么事情。
流程：我要干一件什么样的事情，其步骤是什么，体现的是做的过程。

从划分的结果来看，能力划分和流程划分是一致的，但从思考的角度看是不同的。从划分的确定性看，因为角色有限，能力从结果和目标的角度出发，避开路径的复杂性，有更强的确定性。

三者的映射关系

第五章已经讨论了域的划分依据——按对象间关系的紧密程度聚合。这里将域与能力、流程放在一起做横向对比。三者的划分依据各有不同，但最终需要建立映射：

概念	划分依据	特点	电商案例
能力	按照完成目标划分	面向结果	"担保交易能力"——帮买家安全完成购买
流程	按照执行过程划分	面向步骤	"下单→支付→发货→收货"——按步骤执行
域	按照实体聚合切分	面向对象	"交易域"——围绕订单对象聚合

业务流程是业务感知结果的流程，系统流程是执行步骤的划分。域内可以有流程，域的多项能力可能对应细分流程的多个步骤，不一定有必然的先后顺序，也可能是离散的能力组合。

域和能力之间也需要在一定的粒度上建立映射关系，否则会造成在域和能力都有很多层次，并在多个层次间建立复杂的映射。

业务建模与业务架构的区别

在独立讲述流程建模或者能力建模的论述中，都强调用业务的语言，构建符合业务习惯的成果。业务建模只强调逻辑的完整性，但是在以 IT 实现为目标的前提下，业务建模和 IT 实现之间必须建立简单的对应关系。

维度	业务建模	业务架构
关注点	业务逻辑的完整性	业务逻辑到 IT 实现的映射
产出	概念模型、流程图	能力地图、域划分、服务定义
约束	只需逻辑自洽	需要与技术实现建立对应关系
受众	业务方	业务方 + 技术方

无论是能力建模或者过程建模，最终要与信息模型建立映射关系。在业务分散而平台支撑要统一的情况下，也可以看作是 IT 在寻找和业务的共同语言。

八、商业能力的划分

第六章的 5W1H 框架解决的是"单个能力怎么描述"的问题，本章要解决的是"一组能力怎么分类组织"的问题——前者是微观语义，后者是宏观结构。

划分的核心原则

能力划分的理论基础来自价值链分析——价值链把企业的能力划分为核心能力和辅助能力，实质是以客户为中心，区分客户与企业两个角色。参考 TMF-eTOM 的划分方式，核心流程进一步细分为基础设施、战略、运营，与生产不直接相关的活动定义为企业管理。

落到具体的划分原则上，核心是围绕客户，以是否与客户诉求直接相关作为基准。在顶层视图中，划分能力和流程的视角是一致的——无论流程视角还是能力视角，都要找出我们能为客户做什么。

因此，我们可以区分三类能力：

客户销售与服务能力——直接面向客户
支撑能力——为前端能力提供基础保障
企业管理能力——支撑组织自身运转

案例：电商交易平台的能力分类——

类型	能力举例
客户能力（前端）	商品浏览与搜索、下单购买、支付、退换货、评价
支撑能力（后端）	商品管理（PLM）、库存管理、物流调度、结算对账、风控
企业管理能力	人力资源、财务、法务、技术基础设施

能力划分的逻辑

能力划分是自顶向下的逻辑分解过程。其出发点首先是角色分析，以满足角色的诉求为目的。

能力类型	划分逻辑	说明
前端能力	按消费逻辑划分	直接服务于客户需求，按客户消费场景进行顶层划分
后端支撑能力	按资源/角色分类	服务于经营者，因内部角色分散，形成面向资源的分散流程

场景的细分本身可以构成能力细分的逻辑基础，但仍需要找到场景细分的逻辑。后端支撑能力本质是服务于经营者，可以从经营者的诉求进行划分。但因为内部角色的分散，难以在顶层形成贯穿全局的流程主线，就会形成面向资源的分散流程。这里的资源，本质就是我们所说的域。

这代表了一类细分的思路：在场景细分的基础上，通过资源的分类完成下一级的细分。即便到了资源的分类层次，仍有可能进一步细分，这又会回到场景划分的逻辑。所以，业务能力建模的过程也是在不断寻找不同层次的能力切分逻辑的过程。

从全局看，核心是以客户为中心进行能力的划分。实际上，每一部分能力都服务于生态中的某个特定角色，所以在能力的描述上，直接满足的是当前角色的价值要求，间接地通过以客户为中心的视角进行原则性校验。

企业能力生态闭环

企业的能力围绕"客户、企业自身、合作伙伴"的生态形成闭环
前端围绕满足客户需求
后端分为满足生产要素管理和满足企业自身管理
企业管理暂不涉及

能力划分全景图

九、商业能力层的设计

商业能力层和域内的关系

商业能力是客户可直接感知的能力。越是面向客户直接交互的层次，在技术上越难以限制其差异性，可能会与需求直接映射；越是趋近技术实现的层次，越是需要更高的抽象，以间接满足需求。

商业能力层提供流程性的封装，在顶层按照与客户的交互场景划分，并结合域的划分进行分解：

商业能力层：以提高交互场景的合理性和对外的灵活性为目标，关注面向客户体验的逻辑实现
域内：以实现领域内的接口复用为目的，提供合适粒度的接口，与商业能力层确认概念模型

商业能力团队应该首先是一个设计团队，其次才是一个实现团队。设计应该是和各域一起探讨的过程，商业能力要限制向下层过度延伸，也要迫使下层更注重域内抽象。

在设计过程中，逻辑分解应该尽量形成在各域的独立逻辑，然后组合成对外的交互逻辑。最外层交互所依赖的服务都在商业能力层实现封装，应该以业务设计结果为准，而不是技术设计。对外的扩展点，都在商业能力层定义和体现。

案例："下单"是一个商业能力。它的实现需要调用商品域（查商品信息）、库存域（扣库存）、交易域（创建订单）、营销域（计算优惠）。但对外暴露的是一个完整的"下单"接口，而不是让调用方自己去编排四个域的接口。

商业能力在软件结构上的分层

如果对外提供的就是商业能力，那么域和商业能力的边界到底在哪里？

所有在 SDK、RPC 接口中对外提供调用或者是 SPI 提供实现的，都在商业能力层定义
需要提供给外部使用或扩展的（这里不包含界面层对后端的调用，界面是软件的一部分）

如何界定"内"和"外"？

视角	"内"	"外"
业务平台 vs 业务方	业务平台	业务方
整个中台	所有中台能力	中台以外
企业内外	企业	客户

域间调用规则

域间是否允许调用？调用规则如下：

调用类型	是否允许	说明	案例
依赖另一个域的实体对象信息的查询调用	允许	不限制下层的信息查询	交易域查询商品域的商品信息
依赖另一个域的判断的调用	禁止	交给上层去集成	交易域不应直接调用风控域判断是否拦截
嵌入另一个域的处理环节的调用	禁止	限制下层的逻辑蔓延	商品域不应嵌入交易域的下单流程

核心原则是：上层进行逻辑和控制结构的组装，不限制下层的信息查询，但限制下层的逻辑蔓延。

对于下层能够独立完成的判断逻辑或处理环节，鼓励下层去做。但对象必须有属主域，判断应该是本域的关键对象的行为判断，而不能是跨越边界。只有直接被认为是对象的直接属性的内容，才被认为是查询，所以对于一个域要有基本的概念模型。

从概念性的能力到软件实现的层次

能力到软件实现的映射

能力的表现形式：

高层的能力：应该是逻辑的表达，对应于软件的整体或可独立交付的部分
低层的能力：应该和软件的外在存在形式关联，如分布式环境中的服务接口、SDK 中定义的接口

能力的划分原则：

能力是围绕以完成客户诉求为目标来划分的，完成一个能力可能需要多个领域对象的协作。能力的细分有横向和纵向的划分方式，未必代表软件实现的粒度细分，所以要建立能力和软件实现的映射关系。但在能力粒度上，一定需要和软件的交付物有一致并且明确的边界。

十、常见反模式与误区

方法论容易讲得"正确但无感"。以下是在业务平台架构实践中反复出现的几个典型反模式，每一个都有巨大的隐性成本。

反模式一：过度平台化

表现：什么都想沉淀为平台能力，每个业务需求都先问"能不能做成通用的"。

后果：平台变得臃肿，充满了"为未来设计"但从未被第二个业务线使用的通用抽象。业务方被迫适配平台的通用模型，而不是平台适配业务——本末倒置。

判断标准：一个能力如果只有一个业务方使用，且短期内看不到第二个使用方，就不应该沉淀到平台层。复用应该是被发现的，而不是被设计的——先让两三个业务线各自实现，再从中提取共性。

案例：交易平台曾试图为所有业务线统一"优惠计算引擎"。但淘宝的满减、天猫的品牌券、1688 的阶梯价差异极大，强行统一后引擎变得极度复杂，每次修改都要回归全量业务线。最终拆回各业务线自行实现优惠逻辑，平台只提供"优惠接口规范"。

反模式二：域划分过细或过粗

过细的表现：每个实体都拆成独立的域（如"地址域"、"发票域"），导致一个简单的业务操作需要跨 5-6 个域协调。

过粗的表现：把商品、交易、支付都放在一个"核心域"里，域内耦合严重，改一处牵一片。

判断标准：域的粒度应该使得域内高内聚、域间低耦合。一个实用的检验方法是——如果两个候选域之间的调用频次远高于它们各自与其他域的调用频次，那它们可能应该合并；如果一个域内部存在两组对象，彼此之间几乎没有交互，那它们可能应该拆分。

反模式三：能力层和域层职责混淆

表现一：商业能力层做了太多域内逻辑——能力层不仅编排流程，还实现了具体的业务规则（如库存扣减的并发控制），导致域层变成空壳。

表现二：域直接暴露了面向客户的接口——域的接口设计按照客户场景设计而非按照对象能力设计，导致域与域之间出现大量重叠的接口。

原则：能力层负责编排（"先做什么后做什么"），域层负责实现（"怎么做"）。能力层不应该知道库存是用乐观锁还是悲观锁扣减的，域层不应该知道当前请求来自淘宝还是天猫。

反模式四：概念模型缺失导致"各说各话"

表现：不同团队对同一个业务对象的理解不一致——交易团队说的"订单"是买家视角的购买记录，物流团队说的"订单"是发货指令，财务团队说的"订单"是结算凭证。

后果：系统之间的数据传输需要大量的"翻译层"，Bug 频发且难以排查。

解法：建立全局一致的概念模型（Canonical Model），明确每个核心对象的定义、归属域、与其他对象的关系。概念模型不需要包含所有字段细节，但必须对"这个词在我们公司是什么意思"达成共识。

十一、组织与架构的关系

康威定律（Conway's Law）指出：系统的架构会趋向于反映组织的沟通结构。在业务平台架构中，这条定律的影响无处不在。

域的边界和团队边界

关系模式	说明	效果
域 = 团队	一个域对应一个团队，团队完全拥有域内的代码和数据	效率最高，责任最清晰
域 > 团队	一个域由多个团队共同维护	协调成本高，容易出现"公地悲剧"
域 < 团队	一个团队维护多个域	可行，但团队需要有清晰的域边界意识，否则域间耦合会被"内部方便"侵蚀

实践建议：理想情况下，域的边界应该和团队边界对齐。如果做不到（早期团队小），至少要让每个域有一个明确的 Owner（即使 Owner 同时负责多个域）。

平台团队和业务团队的协作模式

模式	说明	适用场景
共建	业务团队向平台提 PR，平台团队 Review 后合入	平台能力演进快，业务方有技术能力
提工单	业务方提需求，平台团队排期实现	平台稳定期，业务方无平台开发能力
自助	平台提供 SPI/扩展点，业务方自行实现差异化逻辑	平台成熟，扩展点设计完备

最终目标是走向"自助"模式——平台提供足够的扩展机制，业务方不需要等平台排期就能实现差异化需求。这要求平台的扩展点设计必须足够开放和稳定。

当组织结构和架构不匹配时

如果组织结构和架构不匹配，通常会出现以下症状：

跨团队联调频繁：一个简单的业务需求需要 3-4 个团队配合才能上线
变更连锁反应：A 团队的改动导致 B 团队被迫跟着改
责任模糊：出了问题找不到明确的负责人

解法要么是调整架构适配组织（重新划分域的边界），要么是调整组织适配架构（重组团队）。前者短期成本低但可能引入技术债，后者短期成本高但长期效果好。

十二、基于企业架构，构建业务架构

要想构建业务平台架构，我们需要有一套行之有效的构建方法论。方法论的构成包括：原理过程 + 表示法 + 工具。

能力地图代表业务架构，概念模型代表信息架构。对于多数业务平台，技术架构一般已经有较为明确的选择。所以，业务平台亟需构建的是除技术架构之外的泛"业务架构"。

从企业管理维度上看，企业架构在业务平台通常可以解决的问题包括：

研发投资的价值识别
架构演进的组织方法
组织的职责划分

构建架构体系：战略→模式→能力→过程

业务架构不是凭空生长的，它的输入和输出构成一条从战略到落地的链路：

层次	输入	产出	案例
战略	公司业务方向、市场定位	业务架构的边界和优先级	"未来一年重点做跨境电商" → 跨境交易能力优先建设
模式	商业模式、运营模式	能力组合的模式模板	"B2C 模式"需要商品展示+购物车+支付的组合；"B2B 模式"需要批量采购+账期+合同的组合
能力	模式分解后的功能需求	能力地图（第八章的三类能力划分）	"担保交易能力"、"分期支付能力"
过程	能力的执行路径	流程定义 + 域间协作关系	"下单→锁库存→支付→扣库存→发货"

这条链路的关键约束是：上层决定下层的边界，下层反馈上层的可行性。战略说"做跨境"，能力层评估"跨境支付能力缺失，需要 3 个月建设"，这个反馈会影响战略的优先级排列——这是一个双向迭代过程，而非单向瀑布。

从产品视角看，产品目录既是业务架构的延续（每个产品对应一组能力），也是应用架构的延续（每个产品对应一组技术组件）。应用架构的边界和域的边界有内在的关联，可以通过自顶向下的讨论以及循环迭代完成演进。

构建能力地图

步骤	内容	产出
1. 确定架构定义及结构描述	明确分层规则：哪些是客户能力、支撑能力、企业管理能力	能力分类标准文档
2. 现状描述	梳理现有系统已具备的能力，标注归属域和服务等级	能力地图草稿（现状版）
3. 搜集关键场景，确定目标架构	收集业务规划中的关键新场景，识别需要新增或增强的能力	能力地图（目标版）
4. Gap 分析	对比现状和目标，识别能力缺口和冗余	Gap 清单
5. 演进计划	按业务优先级和技术依赖关系排列能力建设的时间线	路线图（Roadmap）
6. 构建基础完备正交集合	确保能力之间不重叠（正交）、不遗漏（完备）	能力地图（正式版）
7. 构建不同场景的视图	按不同受众生成子视图	外部客户视图、内部热点视图

构建概念模型

阶段	内容	产出
现状搜集	梳理已被广泛引用的概念和实体、已被广泛使用的术语、已被固化的流程节点、已广泛使用的场景	概念清单 + 术语表
未来场景搜集	从战略输入和业务规划中识别新的概念和实体	补充概念清单
建模	域划分（根据对象关系紧密程度）、模型定义（核心对象+关系+属性）、耦合验证（域间依赖是否合理）	概念模型图 + 域划分文档
演进计划	识别概念模型和现有系统的差距，制定迁移计划	数据迁移路线图

十三、演进路径

业务平台架构不是一蹴而就的，它有明确的阶段性特征。

三阶段演进

阶段	特征	架构重点	典型信号
单体期	1-2 条业务线，团队 < 20 人	快速交付，不需要平台化。核心是代码结构清晰，模块边界明确	"所有代码在一个仓库里，改起来很快"
拆分期	3-5 条业务线，团队 30-50 人	开始抽取共享服务（用户、支付、商品），域边界开始清晰	"两个团队改同一个模块频繁冲突"
平台期	5+ 条业务线，团队 50+ 人	商业能力层成型，扩展点机制完善，业务方可自助接入	"新业务线接入需要 3 个月以上"

什么信号表明"该拆了"

两个业务线的需求频繁在同一个模块上冲突
一个简单的功能改动需要多个团队联调
新业务线接入时需要 fork 大量代码
发布一个模块需要回归不相关的业务线

什么信号表明"该合了"

两个"独立"的服务之间每次变更都必须同步发布
一个用户请求需要跨 5 个以上的服务才能完成
服务间的调用延迟累积导致性能问题
维护成本（监控、告警、部署）超过了拆分带来的收益

新业务接入平台的标准流程

步骤	内容	产出
1. 业务身份注册	为新业务线分配全局唯一的业务身份	业务身份 ID
2. 能力评估	评估新业务线需要哪些平台能力，哪些需要定制	能力使用清单 + 定制需求清单
3. 扩展点实现	业务方基于平台的 SPI 实现差异化逻辑	扩展点代码
4. 规则配置	将业务规则关联到新的业务身份上	规则配置
5. 联调与验证	端到端验证新业务线的核心流程	测试报告
6. 灰度发布	小流量验证后逐步放量	上线

总结

业务平台架构的构建是一个系统性工程，其核心在于找到业务与技术之间的共同语言。回顾全文，可以提炼出以下关键认知：

业务身份是差异性管理的基础——通过全局一致的业务身份，区分需求来源和规则适用范围，新业务线接入时"挂载规则"而非"修改代码"
能力、流程、域三位一体——能力面向结果，流程面向过程，域面向对象，三者需要在合适的粒度上建立映射
以客户为中心的划分逻辑——无论前端能力还是后端支撑，最终都服务于客户价值的交付
商业能力层是关键的架构抽象——它既要限制向下层的过度延伸，又要迫使下层注重域内抽象
域间调用的原则——允许信息查询，禁止逻辑蔓延，上层负责编排
组织结构和架构必须匹配——康威定律决定了域的边界最终要和团队边界对齐，否则协调成本会吞噬架构的收益
复用应该被发现而非被设计——过度平台化比平台化不足更危险，先让业务跑起来，再从实践中提取共性
业务架构需要持续演进——通过能力地图和概念模型的迭代构建，配合明确的演进信号（"该拆了"还是"该合了"），逐步完善架构体系

好的业务平台架构不是一蹴而就的，它需要在实践中不断验证和演进。关键是始终保持以业务视角为出发点，用结构化的方法将业务逻辑转化为可落地的技术架构。