领域驱动设计 读书笔记 (3)

上下文是最不容易引起注意的原则，实际上却是最根本的。无论大小，成功的模型必须在逻辑上一致，不能有互相矛盾或重叠的定义。有时，企业系统会集成各种不同来源的子系统，或包含诸多完全不同的应用程序，以至于无法从同一角度看待领域。要把这些部分中隐含的模型统一起来可能太难了，通过为每个模型显式定义一个BOUNDED CONTEXT，然后在必要的情况下定义它与其他上下文的关系，模型就不会变得掺杂不清。
通过精炼可以减少混乱，并且把注意力集中到正确的地方。整体领域模型需要突出系统中最有价值和最特殊的那些方面。
大型结构是用来描述整个系统的。

保持模型的完整性

模型最基本的要求是保持内部一致性，又叫统一，unification。
在系统的各个不同部分中开发多个模型是很有必要的。但我们必须慎重选择系统的哪些部分可以分开，以及他们之间是什么关系。我们需要用一些方法保持模型关键部分的高度统一。
大型系统领域模型的完全统一既不可行，也不划算。
多个模型的代价：限制了集成，使沟通变得很麻烦。

将大型项目的所有软件统一到单一模型有以下风险：

• 一次尝试对遗留系统做过多的替换
• 大项目可能会陷入困境，因为协调的开销太大，超出了这些项目的能力范围
• 具有特殊需求的应用程序可能不得不使用无法充分满足需求的模型，而只能将这些无法满足的行为放到其他地方
• 另一方面，试图用一个模型来满足所有人的需求可能会导致模型中包含过于复杂的选择，因而很难使用

除了技术上的因素，权力上的划分和管理级别的不同可能也要求把模型分开。而且，不同模型的出现也可能是团队组织和开发过程导致的结果。

创建清晰的共同视图，以保证需要统一的部分保持一致，不需要统一的部分不会引起混乱或破坏模型。

我们需要用一种方式标记出不同模型之间的边界和关系。我们需要有意识地选择一种策略，并一致地遵守它。
BOUNDED CONTEXT定义了每个模型的应用范围，CONTEXT MAP给出了项目上下文和他们之间关系的总体视图。通过SHARED KERNEL紧密关联上下文，SEPARATE WAYS松散耦合。

BOUNDED CONTEXT

明确定义模型所应用的上下文。根据团队的组织、软件系统各个部分的用法以及物理表现（代码和数据库模式等）来设置模型的边界。在这些边界中严格保持模型的一致性，而不要收到模型外问题的干扰和混淆。
在CONTEXT中，要保证模型在逻辑上的统一，而不用考虑它是不是适用边界之外的情况。在其他CONTEXT中，会使用其他模型，这些模型具有不同的术语、概念、规则和UBIQUITOUS LANGUAGE的技术行话。跨边界的集成需要做转换，但是我们可以清楚地分析这些转换。

BOUNDED CONTEXT不是MODULE
这两个概念容易引起混淆。但他们是具有不同动机的不同模式。确实，当两组对象组成两个不同模型时，人们几乎总是把他们放在不同的MODULE中。这样做提供了不同的命名空间（对不同CONTEXT很重要）和一些划分方法。
但是，人们也会在一个模型中用MODULE组织元素，他们不一定要表达划分CONTEXT的意图。MODULE在BOUNDED CONTEXT内部创建的独立命名空间实际上让人们很难发现意外产生的模型分裂。

将不同模型的元素组合到一起可能会引发两类问题：重复的概念和假同源。重复的概念是指两个模型元素（以及伴随的实现）实际上表示同一个概念。每当这个概念的信息发生变化时，都必须更新两个地方。每次由于新知识导致一个对象被修改时，必须重新分析和修改另一个对象。如果不进行实际的重新分析，结果就会出现同一概念的两个版本，他们遵守不同的规则，甚至有不同的数据。更严重的是，团队成员必须学习做同一件事情的两种方法，以及保持这两种方法同步的各种方式。
假同源稍稍少见，但是潜在危害更大。它是指使用相同术语（或已实现的对象）的两个人认为他们在谈论同一件事情，但实际上不是这样。当两个定义都与同一个领域方面相关，而只是在概念上稍有区别时，这种冲突更难以发现。
发现这些问题时，团队必须做相应的决定。可能需要将模型重新整合为一体，并加强用来预防模型分裂的过程。

CONTINUOUS INTEGRATION

当很多人在同一个BOUNDED CONTEXT中工作时，模型很容易发生分裂。团队越大，问题就越大。但是，即使是3、4个人的团队，也可能遇到严重的问题。然而，如果将系统分成更小的CONTEXT，最终又难以保持集中度和一致性。
开发统一的系统需要维持很高的沟通水平，这一点常常很难做到。我们需要运用各种方法来增进沟通并减小复杂性。还需要一些安全防护措施，以避免过于谨慎的行为（比如怕破