12/9-DDD中国峰会部分文章节选

DDD不是架构，而是一种方法论（Methodology）。根据维基百科：Methodology is the systematic, theoretical analysis of the methods applied to a field of study，DDD正是针对软件领域提供的系统与理论分析方法。Eric在创造性地提出DDD时，实则是针对当时项目中聚焦在Data（主要是DB Schema）为核心的系统建模方法的批判。这种面向数据的建模方式无法应对日渐复杂的业务逻辑，也无法更好地应用当时正沸沸扬扬的OO设计思想。这是设计观念的转变，蕴含了全新的设计思想、设计原则与设计过程。
坦白说，Eric Evans的DDD奠基之作《Domain-Driven Design》并没有非常清晰的系统脉络，战略设计与战术设计也未成体系。Eric的DDD其实没有解决三个问题：

• 如何进行领域建模
• 如何识别Bounded Context
• 如何在战术层面寻找对象

DDD不是架构（设计）方法，因此不能把每个设计细节具象化。DDD是一套体系，这就决定了它必须具有开放性，在这个体系中你可以用任何一种方法来解决这些问题。但如果这些关键问题如果没有具体落地的方法，可能会让团队无可适从。这其实也是DDD在许多项目中难以推行的部分原因。

DDD的战略建模与战术建模

战略建模-Strategic Modeling：

1. 限界上下文（Bounded Context）
2. 上下文映射图（Context Mapping）

战术建模-Tactical Modeling：

1. 聚合-Aggregate
2. 实体-Entity
3. 值对象-Value Objects
4. 资源库-Repository
5. 领域服务-Domain Services
6. 领域事件-Domain Events
7. 模块-Modules

Bound Context（BC）

先引用一段文章内容DDD分层架构的三种模式：

UL（Ubiquitous Language，通用语言）是团队共享的语言，是DDD中最具威力的特性之一。不管你在团队中的角色如何，只要你是团队的一员，你都将使用UL。由于UL的重要性，所以需要让每个概念在各自的上下文中是清晰无歧义的，于是DDD在战略设计上提出了模式BC（Bounded Context，限界上下文）。UL和BC同时构成了DDD的两大支柱，并且它们是相辅相成的，即UL都有其确定的上下文含义，而BC中的每个概念都有唯一的含义。
一个业务领域划分成若干个BC，它们之间通过Context Map进行集成。BC是一个显式的边界，领域模型便存在于这个边界之内。领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。
从广义上来讲，领域即是一个组织所做的事情以及其中所包含的一切，表示整个业务系统。由于“领域模型”包含了“领域”这个词，我们可能会认为应该为整个业务系统创建一个单一的、内聚的和全功能式的模型。然而，这并不是我们使用DDD的目标。正好相反，领域模型存在于BC内。

关于BC，有一个很形象的类别，细胞和细胞膜的类比：

细胞之所以能存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，而且确认了什么物质可以通过细胞膜

CONTINUOUS INTEGRATION（持续集成-CI）

定义完一个 BC后，必须让它持续保持合理化。当很多人在同一个BC中工作时．模型很容易发生分裂。团队越大，问题就越大，但即使是3、4个人的团队也有可能会遇到严重的问题。然而，如果将系统分解为更小的 CONTEXT，最终又难以保持集成度和一致性。
所以一个方法是需要经常保持BC的一致，以便当模型发生分裂时，可以迅速发现并纠正问题。像领域驱动设计中的其他方法一样，CI也有两个级别的操作：（1）模型溉念的集成；（2）实现的集成。团队成员之间通过经常沟通来保证概念的集成。团队必须对不断变化的模型形成一个共同的理解，最基本的方法是对 UL多加锤炼，在讨论模型和应用程序时要坚持使用UL。同时，实际工件是通过系统性的合并/构建/测试过程来集成的，这样的过程能够尽早暴露出模型的分裂问题。
建立一个经常把所有代码和其他实现工件合并到一起的过程，并通过自动测试来快速查明模型的分裂问题。严格坚持使用 UL,以便在不同人的头脑中演变出不同的概念时，使所有人对模型都能达成一个共识。
最后，不要在持续集成中做一些不必要的工作。CI只有在BC中才是重要的。相邻 CONTEXT中的设计问题（包括转换）不必以同一个步调来处理。

上下文图（Context Map）

多个系统之间会发生关系，存在交互，这也必然会在各自的BC上有所表现。在项目中创建一个所有模型上下文的全局视图，可以减少混乱。上下文图（Context Map）便是表示各个系统之间关系的总体视图。
建模的过程需要识别每个模型在项目中的作用，并定义其 BC，这包括非面向对象子系统的隐含模型。为每个 BC命名，并把名称添加到 UL。描述模型之间的接触点，明确每次交流所需的转换，并突出任何共享的内容。画出现有的范围。为稍后的转换做好准备。
在Context Map中可以有如下几种形式来表征限界上下文之间的关系，简介如下（具体可阅读原书）：

1. 共享内核（Shared Kernel）

当不同团队开发一些紧密相关的应用程序时，团队之间需要进行协调，通常可以将两个团队共享的子集剥离出来形成共享内核（Shared Kernel），双方进行持续集成（Continuous Integration）。共享内核（Shared Kernel）是业务领域中公共的部分，同时也是团队间容易达成且必须达成共识的领域部分。

2. 客户/供应商（Customer/Supplier）

不同系统之间存在依赖关系时，下游系统依赖上游系统，下游系统是客户，上游系统是供应商，双方协定好需求，由上游系统完成模型的构建和开发，并交付给下游系统使用，之后进行联调、测试。这种模式建立在团队之间友好合作和支持的情况下。
当两个具有上游/下游关系的团队不归同一个管理者指挥时，Customer/Supplier这样的合作模式就不会奏效。勉强应用这种模式会给下游团队带来麻烦。

3. Conformist（追随者）

当两个开发团队具有上/下游关系时，如果上游团队没有动机来满足下游团队的需求，那么下游团队将无能为力。出于利他主义的考虑，上游开发人员可能会做出承诺，但他们可能不会履行承诺。下游团队出于良好的意愿会相信这些承诺，从而根据一些永远不会实现的特性来制定计划。下游项目只能被搁置．直到团队最终学会利用现有条件自力更生为止。下游团队不会得到根据他们的需求而量身定做的接口。
这时候“客户/供应商”模式就不凑效了，那么下游系统只能去追随上游系统，下游系统严格遵从上游系统的模型，简化集成。
通过严格遵从上游团队的模型，可以消除在 BC之间进行转换的复杂性。尽管这会限制下游设计人员的风格，而且可能不会得到理想的应用程序模型，但选择 Conformist模式可以极大地简化集成。此外，这样还可以与供应商团队共享一种 UL。供应商处于驾驶者的位置上，因此最好使他们能够容易沟通。

4. 防腐层（Anticorruption Layer）

前面介绍了在两个BC之间集成时可以进行的各种合作，从高度合作的 Shared Kernel模式或 Customer/Supplier Team到单方面的Conformist模式。如果是一种更悲观的关系，假设一个团队既不可能与另一个团队合作也无法利用他们的设计时，该如何应对。
这时候我们需要使用防腐层（Anticorruption Layer）模式将上游系统的影响降低。

5. 公开主机服务（Open Host Service）

当一个子系统必须与大量其他系统进行集成时，为每个集成都定制一个转换层可能会减慢团队的工作速度。如果一个子系统有某种内聚性，那么或许可以把它描述为一组 Service,这组 Service满足了其他子系统的公共需求。
公开主机服务（Open Host Service）能够允许系统将一组Service公开出去公其他系统访问。定义一个协议，把你的子系统作为一组 Service供其他系统访问。开放这个协议，以便所有需要与你的子系统集成的人都可以使用它。当有新的集成需求时，就增强并扩展这个协议，但个别团队的特殊需求除外。

6. 各行其道（Separate Way）

当两个系统之间的关系并非必不可少时，两者完全可以彼此独立，各自独立建模，独立发展，互不影响。

Context Map例子

例子

U表示上游（Upstream）的被依赖方，D表示下游（Downstream）的依赖方。防腐层（ACL）放在下游，将上游的消息转化为下游的领域模型。

模式图谱

模式图谱