DDD领域驱动设计---入门书籍：第四部分：战略设计

第四部分：战略设计

当我们无法通过分析对象来理解系统的时候，就需要掌握一些操纵和理解大模型的技术了。

战略设计原则必须把模型的重点放在捕获系统的概念核心，也就是系统的“远景”上。而且在完成这些目标的同时又不能为项目带来麻烦。

整体领域模型需要突出系统中最有价值和最特殊的那些方面，而且在构造领域模型时应该尽可能把注意力集中在这些部分上。

上下文：无论大小，成功的模型必须在逻辑上一致，不能有互相矛盾或重叠的定义。

精炼：精炼可以减少混乱，并且把注意力集中到正确的地方。

大型结构：大型结构是用来描述整个系统的。

---

第十四章 保持模型的完整性

模型最基本的要求是它应该保持内部一致，术语总具有相同的意义，并且不包含互相矛盾的规则：虽然我们很少明确地考虑这些要求。模型的内部一致性又叫做统一（unification），这种情况下，每个术语都不会有模棱两可的意义，也不会有规则冲突。除非模型在逻辑上是一致的，否则它就没有意义。

BOUNDED CONTEXT（限界上下文）定义了每个模型的应用范围，而CONTEXT MAP（上
下文图）则给出了项目上下文以及它们之间关系的总体视图。这些降低模糊性的技术能够使项目更好地进行，但仅仅有它们还是不够的。一旦确立了CONTEXT的边界之后，仍需要持续集成这种过程，它能够使模型保持统一。

模式：BOUNDED CONTEXT

任何大型项目都会存在多个模型。而当基于不同模型的代码被组合到一起后，软件就会出现bug、变得不可靠和难以理解。团队成员之间的沟通变得混乱。人们往往弄不清楚一个模型不应该在哪个上下文中使用。

明确地定义模型所应用的上下文。根据团队的组织、软件系统的各个部分的用法以及物理表现（代码和数据库模式等）来设臵模型的边界。在这些边界中严格保持模型的一致性，而不要受到边界之外问题的干扰和混淆。

BOUNDED CONTEXT 不是MODULE它们是具有不同动机的不同模式。

识别BOUNDED CONTEXT中的不一致

最明显的是已编码的接口不匹配。对于更微妙的情况，一些意外行为也可能是一种信号。采用了自动测试的CONTINUOUS INTEGRATION可以帮助捕捉到这类问题。但语言上的混乱往往是一种早期的警告信号。

不同模型的元素组合到一起可能会引发两类问题：

重复的概念和假同源。

重复的概念是指两个模型元素（以及伴随的实现）实际上表示同一个概念。每当这个概念的信息发生变化时，都必须更新两个地方。

假同源可能稍微少见一点，但它潜在的危害更大。它是指使用相同术语（或已实现的对象）的两个人认为他们是在谈论同一件事情，但实际上并不是这样。

当发现这些问题时，团队必须要做出相应的决定。可能需要将模型重新整合为一体，并加强用来预防模型分裂的过程。

模式：CONTINUOUS INTEGRATION

最纯粹的XP非常适合维护单一BOUNDED CONTEXT中的模型完整性。但是，无论是否使用XP，都很有必要采取CONTINUOUS INTEGRATION过程。

CONTINUOUS INTEGRATION是指把一个上下文中的所有工作足够频繁地合并到一起，并使它们保持一致，以便当模型发生分裂时，可以迅速发现并纠正问题。像领域驱动设计中的其他方法一样，CONTINUOUS INTEGRATION也有两个级别的操作：

(1) 模型概念的集成； 在讨论模型和应用程序时要坚持使用UBIQUITOUS LANGUAGE。

(2) 实现的集成。

建立一个把所有代码和其他实现工件频繁地合并到一起的过程，并通过自动化测试来快速查明模型的分裂问题。严格坚持使用UBIQUITOUS LANGUAGE，以便在不同人的头脑中演变出不同的概念时，使所有人对模型都能达成一个共识。

模式：CONTEXT MAP

识别在项目中起作用的每个模型，并定义其BOUNDED CONTEXT。这包括非面向对象子系统的隐含模型。为每个BOUNDED CONTEXT命名，并把名称添加到UBIQUITOUS LANGUAGE中。

描述模型之间的联系点，明确所有通信需要的转换，并突出任何共享的内容。

先将当前的情况描绘出来。以后再做改变。

如果团队需要为不同的用户群提供服务，或者团队的协调能力有限，可能就需要采用SHARED KERNEL（共享内核）或CUSTOMER/SUPPLIER（客户/供应商）关系。有时仔细研究需求之后可能发现集成并不重要，而系统最好采用SEPARATE WAY（各行其道）模式。当然，大多数项目都需要与遗留系统或外部系统进行一定程度的集成，这就需要使用OPEN HOST SERVICE（开放主机服务）或ANTICORRUPTION LAYER（防护层）。

模式：SHARED KERNEL

从领域模型中选出两个团队都同意共享的一个子集。当然，除了这个模型子集以外，还包括与该模型部分相关的代码子集，或数据库设计的子集。这部分明确共享的内容具有特殊的地位，一个团队在没与另一个团队商量的情况下不应擅自更改它。

功能系统要经常进行集成，但集成的频率应该比团队中CONT