解读《领域驱动设计 软件核心复杂性应对之道》（八）

第16章 大型结构

 这章的标题是“大型结构”。其实这章主要在讲“系统大到一定程度后，我们应该怎样整体的去管理和看待这个系统”。如何保证大型系统各个部分能统一朝着正确的方向发展。感觉这章直接叫“战略设计”，可能更好理解一些。比如，“远交近攻”就是战略，但具体应该先“远交”哪些国家，先“近攻”哪些国家，可能大家的观点就会有差异了。但不管有多大的差异，都要在“远交近攻”这个大框架下去制定具体战术。

       与CONTEXT MAP 不同，战略设计需要系统大到一定程度，或者说你负责的系统大到一定程序，才需要考虑的事情。如果系统很小，那么分解为几个MOUDLE完全能解决问题。创建一种既为开发人员保留必要自由度，同时又能保证开发工作不会陷入混乱的结构并非易事，需要有“大局观”。一些技术架构（如j2ee）已经成为主流技术，而人们对领域层中的大型结构却没有做多少研究。因为领域层的战略设计往往需要一事一议，并不像技术上这么容易提炼。但我们还是有一些模式可以参考。 这可能就是作者提到了EVOLVING   ORDER(进化顺序)这个词的原因。只有系统进化到一定程度才会用到这个模式。

在介绍这章的内容之前，我们先来回顾梳理下和领域结构有关的三个概念：AGGREGATE、MOUDLE、BOUNDE CONTEXT 。

• 我们通过AGGREGATE（聚合）将领域中的元素建立起关联关系，各个AGGREGATE通过聚合根进行交互。聚合就像一串葡萄，领域中的元素就是一个个的葡萄粒，聚合根就是手拎的那个位置。
• MOUDLE是对领域元素的分组，目的是通过“高内聚，低耦合”的分组，提高沟通效率，进一步使架构更清晰。
• BOUNDE CONTEXT 强调的是从“管理维度”对领域进行划分。每个BOUNDE CONTEXT 由不同的团队管理和维护。我们还介绍了不同BOUNDE CONTEXT之间的关系。

MOUDLE可以理解为比BOUNDE CONTEXT更小的单元。

我们通过精炼，抓主要矛盾，提取中领域模型中的CORE DOMAIN。CORE DOMAIN可能是BOUNDE CONTEXT的一部分，也可能是几个BOUNDE CONTEXT的合集。我之前也说过，这本书在讲“道”。“道”是理念层面的东西，所以一些概念和模式，大家要领悟精髓，具体落地是什么情况，要具体问题具体分析。       

16.1 模式：SYSTEM METAPHOR(隐喻)

系统大到一定程度，我们需要一个词来很形象的描述它。因为软件设计往往比较抽象，我们需要一个切实可行的方式来理解系统。隐喻就是个很好的办法。比如“防火墙”就是个很好的隐喻。简单直接的表明了目前的技术在做什么事情。我们可以将隐喻直接列为UBIQUITOUS LANGUAGE的一部分。隐喻一定要比较恰当的反应实际情况，避免采用一些“幼稚”的隐喻对大家产生误导。

16.2 模式: RESPONSIBILITY LAYER（职责层）

      系统大到一定程度，为了便于管理，我们以模块MOUDLE粒度将各个模块分到不同的职责层。 有时候，我们可能已经在不自觉的就在按照分层的方式在设计架构了，这时候我们只需要将之前松散的架构再明确一下。那分层有没有什么可以参考的种类或者标准呢？作者给出了五类职责层供参考，分别是能力层、作业层、承诺层/策略层、决策层。

能力层也叫潜能层，这个层不关心我们打算做什么，只关系能做什么。这个层几乎适用于任何业务领域，尤其对那些依靠大型固定资产来支持业务运作的企业。

作业层是我们利用潜能层能做什么事情。作业层对象可以引用潜能层对象，它甚至可以由潜能层构成，但潜能层对象不能引用作业层对象。

承诺层/策略层这两个层比较类似，只是目标的级别不同，承诺层中表述了未来运营的目标；策略层是更宏观的层面规则和目标。这些规则和目标用来约束其他层的行为，有时会通过参数传到较低层。同时，决策层可以检索承诺层/策略层的规则和目标，并受到这些规则和目标的约束。

决策层是用来做出分析或者决策的，很多项目利用数据仓库技术，对现有数据进行统计分析，供领导进行战略决策。

虽然这5个层对很多企业系统都适用，但并不是所有领域的主要概念都涵盖在5个层中。有时候生搬硬套反而适得其反。我们可以根据现状选择一个起点，然后通过EVOLVING ORDER来改进它。

     下层不能约束上层，只能向上层通过事件监听的方式发送信息。

16.3 模式：PLUGGABLE COMPONENT FRAMEWORK

PLUGGABLE COMPONENT FRAMEWORK(可插入式组件框架)可以理解成面向接口编程。从接口和交互中提炼中一个抽象层。后续的代码实现都要在这个抽象层的框架基础上，通过设置具体的实现类进行实现。组件都要通过实现抽象层的接口，集成进来。PLUGGABLE COMPONENT FRAMEWOR允许人们独立开发软件，并把开发软件平滑的集成到庞大的系统中。

  作者在这部分举了一个“艾滋病纪念拼被”的例子。每个需要进行拼被的人只要做到这做到三步（设计；选择材料；制作拼块），就能把自己的那部分拼被集成到整个纪念被中。例子中的三步，可以理解成抽象出的接口。任何实现了这三步的人，都可以拿过来参与拼接的活动。

16.4 模式：KNOWLEDGE LEVEL

KNOWLEDGE LEVEL(知识级别)又是个比较难理解的词，但是其实描述的内涵很简单。我们知道有一种数据叫做“元数据。元数据就是描述数据的数据。比如数据数据库中的数据是一条一条的，描述这一条一条数据的数据，是数据库字段和表名称。对数据库表的描述和表中字段的含义就是元数据。在领域驱动设计的范围内也存在描述领域元素（书中叫“构造块”）关系的内容，这部分内容叫做KNOWLEDGE LEVEL（翻译过来，确实拗口，但是理解上就是这么理解）。

       作者举了一个例子：一个公司，不同的工种要领不同种类的薪水。每个工种对应的薪水种类开始是固定的，写死的。后来又需要去动态调整了。这时候，通过重新设计，有了不同工种与薪水类型随意配对的设计。实际上，工种和薪水类型都还是那几类，只是相互之间的关系更动态，更可管理了。管理这种关系的部分就是KNOWLEDGE LEVEL。

      再直白点说，就是领域中的各个元素是固定的，但是元素之间的关系，是可以通过配置改变的。比如一群演员，他们是领域中的元素。让他们演古装剧，他们就是古代的人。两个人的关系可能是君臣；让他们演现代剧，他们的关系可能是员工和老板。KNOWLEDGE LEVEL控制的是对象或者模块之间的结构和行为。

      16.5 需要注意的几点原则

• 不要滥用框架和死板的地实现大型结构。大型结构最重要的贡献在它具有概念上的一致性，并帮助我们深入地理解模型。每条结构规则都应该使开发变得更容易实现；
• 需要不断迭代，才能获得对战略的更深入的理解；通过重构得到柔性设计。察觉出哪里是频繁需要修改的，哪里是相对稳定的。对需要频繁修改的部分设计的更灵活一些。
• 不要试图面面俱到，先从松散的结构入手，甚至可以先定一个隐喻名称，在理念上达成基本一致。循序渐进，这样可以避免产生混乱。
• 保持团队的沟通和自律。用高效的沟通保证大家在理念上的一致。同时将大型结构中的一些概念合并到UBIQUTITOUS LANGUAGE中。