第6章 使用有界上下文维护领域模型的完整性

第6章 使用有界上下文维护领域模型的完整性.

在代码中分割和定义出职责边界

保护领域核心部分的完整性

在何处定义边界

在大型复杂的应用程序中，会发现有多个模型在发挥作用。每个模型都被构建表示问题域的不同区域，其中具有使用适合问题复杂性的合适代码设计模式的每一个实现。

理想情况下，每个子域都会有一个模型；但是复杂子域可能包含多个模型并且一些模型可能跨越两个或者多个子域。

在代码中保护每个模型的完整性并且清晰定义其职责边界置关重要。

这是将模型绑定到特定上下文来达到的，该特定上下文称为有界上下文。有界上下文是基于团队的语言实体构建等来定义的。

 

1. 单个模型的挑战

领域驱动设计的核心是需要在代码中创建明确的，可演化的模型，这些模型要与共享概念模型保持一致。在获得新的见解之后，可以将他们有效地纳入模型之中。

1. 1. 模型的复杂性可能会增加

大模型能适应许多领域概念，实现许多业务用例，但是由于将不断将新业务新实例加入模型中，该模型的概念和依赖项的数目增加，从而造成复杂性增加，进而导致出错概率增加，找出你寻求的内容困难，且慢慢导致再次增加新功能和改进的速度变慢，甚至无法维护和实现。

1. 1. 多个团队处理当模型

复杂代码只是单个模型带来的问题之一。

协作的成本以及低效率的组织也是单一模型很可能会导致的主要问题。比如，功能迭代互相影响，代码重叠严重，分支策略复杂等，对于组织频繁有效交付业务价值和了解其客户的能力来说可能会是一个很大的障碍。

总之，代码越复杂，协作成本越高，代码库也越复杂。

 

1. 1. 模型语言中的歧义

DDD实践者所得到的顿悟之一就是认识到系统中有些概念非常相似—他们的名称可能都是相同的。但是对于不同的业务有着不同的内容含义。比如“单据”概念。对于销售部门和客户部门不一样。

1. 1. 领域概念的适用范围

有时，问题域中的单个物理实体可能会被错误归类成代码中的单个概念。比如“产品”。

1. 1. 集成遗留代码或第三方代码

选用较小模型的另一个原因是，与遗留代码或者第三方代码的集成没有那么麻烦。

 

1. 1. 领域模型并非企业模型

在某些情况下，使用整个系统的单个模型是有用的，其中包括业务信息（BI）和报表。

不过，企业模型并非创建能明确表达领域概念的可演化领域模型的最佳解决方案。

企业模型可以基于“数据仓库”方案来创建一个企业模型。