战略设计部分：整合界限上下文，共享内核模式

       

目录

     合作模式

      合伙人模式

      共享内核模式         

        界限上下文模式不仅保护了统一语言的一致性，还支持建模。如果不指定模型的目的—它的边界，就不能构建模型。边界划分了术语的责任。一个界限上下文中的术语可以对业务域建模以解决特定的问题。另一个界限上下文可以定义相同的业务实体，但对它们进行建模以解决不同的问题。

        此外，不同界限上下文中的模型可以独立地演化和实现。也就是说，界限上下文本身并不是独立的。正如系统不能由独立的组件构建，组件必须彼此交互以实现系统的总体目标。在界限上下文中的实现也是如此。虽然它们可以独立发展，但它们必须彼此集成。因此，界限上下文之间总是存在接触点。这些被称为协议。

        协议怎么定义，取决于于界限上下文的模型和语言的差异。由于每个协议都影响到不止一方，因此需要对其进行定义和说明。另外，根据定义，两个界限上下文使用不同的统一语言。系统最终整合时将使用哪种语言?这些整合问题应该通过解决方案的设计进行评估和解决。

        在本章中，您将了解用于定义界限上下文之间关系和整合方法的领域驱动的设计模式。这些模式是由在界限上下文中工作的团队之间的协作特性驱动的。我们将把模式分为三种，每种代表一种团队协作类型:合作模式、消费者-提供者模式和独立模式。      

     合作模式

        合作模式进行的是否顺利，依赖界限上下文中的团队的良好沟通。

        在最简单的情况是由单个团队实现界限上下文。这也适用于具有相互依赖目标的团队，即一个团队的成功取决于另一个团队的成功，反之亦然。界限上下文落地实现的成功与失败，取决于两个团队的沟通和协作质量。

        让我们看看适合合作团队的两种DDD模式:合伙人模式和共享内核模式。

      合伙人模式

        在合伙人模式中，界限上下文之间的集成以特殊方式协调。一个团队可以通知第二个团队关于API的更改，第二个团队将进行合作和改编目的是避免理解偏差和冲突，如下图：

partnership 模式

        这里的整合是需要双向协作的，一个团队无法完成上下文之间协议的定义。单个团队可以找出差异并选择最合适的解决方案。此外，双方合作解决任何可能出现的整合问题。双方都不想阻止对方。

        以这种方式成功集成，需要良好的协作实践、高水平的承诺和团队之间频繁的同步。这种模式可能不太适合地理上位置比较分散的团队，因为它可能会带来信息同步和通信方面的挑战。

      共享内核模式         

        尽管界限上下文是模型边界，但仍然会出现子域的相同模型或其子域的一部分将在多个界限上下文中实现的情况。必须强调的是，共享模型是根据所有界限上下文的需要设计的。此外，共享模型必须在使用它的所有界限上下文之间保持一致。

        例如，考虑一个使用定制模型来管理用户权限的企业系统。每个用户的权限可以直接授予，也可以从他们所属的一个组织单元继承。此外，每个界限上下文都可以修改权限模型，而且每个界限上下文应用的更改必须影响使用该模型的所有其他界限上下文。如图：

共享内核模式

共享作用域

        重叠部分的模型将参与其中的界限上下文的生命周期耦合在一起。对共享模型所做的更改会立即影响到所有界限上下文。因此，为了最大限度地减少更改的级联影响，重叠模型应该受到限制，只公开模型中必须由两个界限上下文实现的那部分。理想情况下，共享内核将仅由集成契约和数据结构组成，这些数据结构旨在跨界限上下文的边界传递。

 实现

        共享内核的实现使得对其源代码的任何修改都会立即反映在使用它的所有界限上下文中。如果组织使用单一存储库方法，则这些文件可以是由多个界限上下文引用的相同源文件。如果不能使用共享存储库，则可以将共享内核提取到专用项目中，并在界限上下文中作为链接库引用。无论哪种方式，对共享内核的每次更改。必须为所有受影响的有界上下文触发集成测试。

        由于共享内核属于多个界限上下文，因此需要不断整合更改。不将共享内核更改传播到所有相关的界限上下文会导致模型中的不一致：界限上下文可能依赖于共享内核的过时实现，从而导致数据损坏或运行时问题。

什么时候使用共享内核模式

        共享内核模式的主要适用性标准是复制成本与协调成本。由于该模式在参与的界限上下文之间引入了强烈的依赖关系，因此只有在复制成本高于协调成本时才应应用该模式。换句话说，只有在集成由两个界限上下文应用于共享模型的更改比协调共享代码库中的更改需要更多的工作时，才应用该模式。

        整合成本和复制成本之间的差异取决于模型的波动性。它变化得越频繁，集成成本就越高
是。因此，共享内核自然会应用于变化最多的子域:核心子域。

        在某种意义上，共享内核模式与上一章中介绍的有界上下文的原则相矛盾。如果参与的有界上下文不是由同一个团队实现的，那么引入共享内核就违背了这一原则。单个团队应该维护一个有限的上下文。重叠的模型，共享内核--实际上是由多个团队开发的。

        这就是为什么使用共享内核必须是合理的。这是一个务实的例外，应该仔细考虑。实现共享内核的一个常识是当沟通或协作问题阻止实现伙伴关系模式时——例如，由于地理限制或组织架构限制。在没有适当协调的情况下多团队一起实现密切相关的功能将导致集成问题、模型不同步以及关于哪种模型设计得更好的争论。最小化共享内核的作用域可以控制级联更改的作用域，并且为每个更改触发集成测试，是强制早期检测集成问题的一种方法。

        应用共享内核模式的另一个常见用例(尽管是暂时的)是遗留系统的逐步（迭代）现代化。在这种情况下，共享代码库可以作为一种实用的中间解决方案，将系统逐步分解为界限上下文。

        最后，共享内核非常适合集成由同一个团队拥有和实现的界限上下文。在这种情况下，界限上下文的临时集成(伙伴关系)可以随着时间的推移“洗掉”上下文的边界。共享内核可用于显式定义有界上下文的集成契约。