第三章、快速开始 -【1/3】战略设计

DDD的应用实践是一个认知的过程，在实践时团队成员尽量保持同一水平的认知，通俗来说，就是错也要错的一致，同时在落地时要以多数人的认知为基准实施，不能以认知程度高的少数人标准来落地。

初学者可以按本节精炼战略和战术的核心内容先实践。本节中提到的知识点会在后续章节详细展开。概念和术语会随章节内容逐个介绍。在开始之前有必要先澄清两个概念，以免造成混淆：

• 应用：指物理存在且可部署的软件单元，在java程序中一般分为两种，一种是提供用户操作界面的web端应用一般为.war包形式存在；另外一种是提供API的数据中心应用以.jar包的形式存在;
• 系统：多个应用的集合，是应用的逻辑组合，其本身只是一个代号。比如用户管理应用 流程管理应用 SSO应用共同组成了OA系统

一个虚构的系统

在设计开始之前，我们先虚构一个简单的协同系统，此协同系统采用scrum管理方式，采用传统的scrum模型，主要包括：Product(产品)、Release Plan(发布计划)、Backlogitem(待办项)、sprint(冲刺项)、Team(负责团队)、Product Owner(产品负责人)、Task(任务)、Priorit(优先级)，业务模型经过初步分析后，如下图所示：

业务规则大概如下：

• 产品由三部分组成：待办、冲击、已发布；
• 产品归属于产品负责人；
• 一个待办项包含若干任务，而且都会有一个优先级用于标识其重要程度；
• 产品负责人可以已在发布计划中的待办项提交到冲刺中；
• 当待办项被提交冲刺中后，需通知冲刺方；

下面我们就以这个虚构的业务案例为背景，看下DDD是如何应用到软件系统设计中的。由于DDD中的概念和规则还是挺多的，所以在每节的开头会先解释下DDD中相关的术语，然后再以本案例进行分析，读者也可以先按照DDD的概念分析本案例，最后对比笔者的分析，可能会达到事半功倍的效果。

战略设计

DDD中的战略主体是业务，并不是由公司经营者制定的以运营或管理为目的的那种战略规划。详细来讲是指以业务为核心，合理的设计模型（领域）、划分（限界上下文），再综合组织架构、技术等因素辅以相应的集成策略（上下文映射）。

术语

• 限界上下文（bounded context）：语义和语境上的边界用来封装通用语言和领域模型，在边界内的模型都有特定的含义并处理特定的事务；
• 通用语言（ubiquitous language）：不是指特定的法语、英语这种规则比较明确的语言，它是指贴合业务并经过提炼后能被所有团队成员沟通的短语；通用语言有几个特征：a、受限于上下文，在同一上下文中没有二义性；b、贴合业务；c、持续提炼；d、能被所有团队成员理解；
• 领域（domain）：域是一个概念，用于封装业务模型；应用于高层设计，比如业务间、也可用在具体业务的子域中。一个业务系统的成功取决于它所提供的多种功能，将这些功能分开是有好处的。在DDD中，一个领域被分为若干子域，领域模型在限界上下文中完成开发。
• 领域模型（model）：可理解为与业务对应的实体，比如用户，角色；

• 在权限管理系统中，包含用户、资源、角色三个限界上下文；
• 在用户限界上下文中包含用户域；
• 在用户域中包含用户组、用户两个模型，在角色域中包含角色、用户两个模型；

注意”用户”出现在了两个域中，但业务含义是不一样的。在用户域中多指真实存在的人或系统，关注用户身份、密码等属性，在角色域中的用户一般是指系统的操作者，一般只需关注用户标识即可。

实施步骤

第一步、划分限界上下文

从业务上划分模型的职责和边界，传统模式下业务模型一般会以E-R图、数据模型图或是图 表的方式来表述，关注点通常是实体属性、数据导航等，然后把模型划分到不同的系统模块中来表述隔离，如下图所示（图中的M指模型是Model的缩写）：

实际上系统模块并不适合做为业务模型间隔离的依据，严格来讲系统模块本质上更趋向于终端应用界面的展现、模型才是是业务的映射，模型间的隔离也需要从业务角度来划分会更为合适。因此系统模块和业务模型本质上是没有直接关系的。本节中所说的上下文划分正好弥补了上述设计过程中的不足，下图展示的是限界上下文划分的过程，左下方框内是拆分后的限界上下文。

一般会先先识别出核心业务，然后再丰富模型。上图中最左侧是去掉模块后的传统业务模型，蓝色的三个步骤是建议的限界上下文的拆分过程，每一步的过程及要点如下：

1. 识别核心模型：找出业务中最最核心的部分（比如商品管理中心，一般包含商品管理、问答管理等多个模块，但最核心的应该只是商品信息，而不包含问答管理），用一个椭圆把最最核心的模型圈起来起一个名称，这就是DDD中限界上下文的图形表示方法，暂且称为”核心上下文”，实际分析时需要用真实的业务术语代替”核心”二字，比如商品上下文、订单上下文；
2. 统一语言：明确定义上下文中各个模型的术语及含义，保证任一模型在此限界上下文中的唯一性，这里只保证名称唯一性即可，在下节提炼时会再复盘这个过程；
3. 丰富核心模型：贴合业务重新审视核心上下文中的模型并进行必要的增删，还是以商品中心举例，商品除了基本信息外，一般还需要与之对应的库存信息，否则在实际业务中商品是无法售卖的；
4. 当用核心上下文圈定的核心模型梳理完成后，重复上面的3步分堆非核心模型，直到所有模型都归属到特定上下文中；

经过分析后，协同系统的模型拆分如下：

第二步、提炼通用语言

用业务术语命名模型，拉齐认知，方便团队沟通。当限界上下文划分完成后，我们有必要全部重新审视一次，就好比考试答完试题后的复查，并用下面的表格记录所有提炼出来的业务短语，并在全团队范围内明确。软件最终交付的是代码，但交付不了知识。但在迭代过程中需要把知识传递下去，可以把通用语言看作知识传递的方式，可视化的表格就是这种知识的载体，建议用excel表格即可，最好是在线的那种。

• 通用语言：不局于名词也可以是动词短语，比如领域事件最好用动词的过去式来命名；
• 类型：在DDD中一共包含7种类型的模型，比如域、事件、聚合根等，在战术部分会详细说明；
• 详细说明：可以是通俗的解释，也可以通过场景的方式描述（如上述表格的第三行）；

第三步、划分子域

定义价值，DDD战略是通过业务价值分析划分领域类型进而制定战略的。子域划分除了可以识别出对组织最有价值的模型，同时也可为系统建设在优先级、投资规模、架构设计、产品定位等一系列活动过程中提供决策依据。DDD中的域可以分三类：

• 核心域：唯一的、定义明确的领导模型是业务中最重要的部分，是核心竞争力的体现；在系统建议时对核心域要有资源倾向性；
• 支撑子域：核心域的成功离不开它，但它又不是业务的核心部分，在系统建设时一般提供定制开发，架构设计时需要考虑其可替换性；
• 通用子域：指通用功能，一般来讲市场上已经有很多成熟的产品了，在系统建设时往往倾向于采购；

经过分析后，此时应该会有多个限界上下文，其中之一必定会成为核心域，而其它的则成为支撑域或通用域。我们用绿色表示核心域、黄色表示通用域、粉色表现支撑域。经过分析后，协同系统的上下文划分如下图所示：

第四步、上下文映射

制定上下文间集成策略，这是战略设计的最后一步。前面我们已经按内聚性、不变性、价值等维度划分了业务模型，本质上业务运行过程中是少不了任何一个模型的。这一步我们需要再把他们联系起来。DDD中用下图所示方法表示，如果需要关联，则在两个椭圆间画一条不带简单的实线，线上标识U和D，U表示上流，D表示下游。

注意，这里的上下游关系并非应用间API接口调用的表述，而是纯粹的业务映射，比如订scrum上下文必须依赖团队管理上下文。同时这个映射关系有时需要考虑组织架构的影响，比如由两个团队负责开发协同系统，负责团队管理应用的团队就是不提供API接口给Scrum团队，虽说业务上依赖，但在这种情况下scrum团队就需要重新考量了，是组织升级还是自建。

在DDD共总结了8种映射策略，本小节先介绍两种常见的映射策略，其它的会在后续章节详细展开：

• 合作关系：日常工作上两个团队可能存在交叉影响，此时映射关系本质上依赖高度的承诺，但需要注意时效性因为长久的稳定合作关系很难维护；
• 客户供应商：比较常见，双方高度协同，比如前台（客户）对中台（供应商）的依赖，此时映射关系本质上由供应商主导；在系统建设时建议客户按自己的预期测试供应商的接口，辅助供应商升级，并把这些测试变成供应商测试的一部分；

经过分析的，协同办公的上下文映射如下图：

第五步、补充上下文映射

软件系统实质上是一种IT技术的编码实现，在战略设计过程中除了考虑业务、业务价值、组织架构等因素，个人认为是有必要加入技术考量的。

比如：在应用集成时，上游团队提供的接口有可能是Soap、Restful、Mq、SDK等多种形式，相对来讲，同样复杂度的服务不同协议类型的接口性能是不一样的。如果我们的业务对性能、安全有要求，在上下文映射时就需要考虑技术因素。下图是一个简单示例（PL=已发布语言、OHS=开放主机服务、ACL=防腐层）：

• C1-G1：上游G1，下游C1，映射策略是共享内核，类似java应用共享.jar包方式；
• C1-G2：上游G2，下游C1，映射策略是已发布语言，类似数据中心的方式；
• C1-S1：上游C1，下游S1，映射策略是开放主机服务，类似Rpc方式的调用；

补充后的上下文映射如下图所示：

• 配置管理上下文中包含优先级管理，它和核心的Scrum上下文采用共享内核的方式集成，一般来说就是实现代码打包在一起部署；
• 团队管理上下文，将来会一个单独的应用形式部署，它和Scrum上下文之间通过Rpc接口相互调用，集成时在Scrum上下文中做一层防腐层以隔离自己的内核不会受团队管理应用的API变化而变化；

战略设计结果