第五章：战略设计的提炼

　　你如何专注于你的核心问题，避免陷入困境？

　　蒸馏提炼是分离混合物组分以提取精华的过程，使其更有价值和有用。模型是知识的升华。通过对重要洞察力的每次重构，我们抽象出领域知识和优先级的一些关键方面。现在，为了获得战略观点，本章将探讨如何区分模型的广泛区域并将域模型作为一个整体进行提炼。

核心域

　　在一个大型系统中，有许多做出贡献的组件，都是复杂的，并且都是成功所必需的，领域模型的本质，即真正的商业资产，会被模糊和忽略。

　　严酷的现实是，设计的所有部分都不会同样精致，必须设定优先顺序，为了使领域模型成为资产，该模型的关键核心必须是时尚且充分利用来创建应用程序功能。但是，稀缺、高技能的开发人员往往倾向于技术基础设施，或可以在没有专业业务领域知识的情况下理解的整齐可定义的领域问题。

因此：

　　将模型煮沸蒸馏，定义核心域并提供一种方法，可以轻松地将其与大量支持模型和代码区分开来。带来最有价值和最专业的概念，让核心变小。

　　将顶尖人才应用于核心领域，并相应招聘，花费精力在核心上寻找深层模型并开发一种柔软的设计 - 足以实现系统的愿景。

通过如何支持蒸馏核心来证明对任何其他部分的投资。

通用子域

　　模型的某些部分增加了复杂性，而没有捕获或传达专业知识。任何无关紧要的事情都会使核心领域难以辨别和理解。该模型充斥着每个人都知道的一般原则或属于专业的一般原则，这些专业不是您的主要关注点，而是起辅助作用。然而，无论多么通用，这些其他元素对于系统的运行和模型的完整表达至关重要。

因此：

　　确定不是项目动机的内聚子域。分解这些子域的通用模型并将它们放在单独的模块中。不要在其中留下您的专长。

　　一旦它们被分离，给予它们持续开发的优先级低于核心域，并避免将核心开发人员分配给任务（因为他们将从他们那里获得很少的领域知识）。还要考虑这些通用子域的现成解决方案或已发布的模型。

领域愿景声明

　　在项目开始时，模型通常甚至不存在，但是关注其开发的需求已经存在。在后期开发阶段，需要对系统的价值进行解释，而不需要对模型进行深入研究。此外，领域模型的关键方面可能跨越多个有界上下文，但根据定义，这些不同的模型无法构建以显示其共同焦点。

因此：

　　写一个核心域的简短描述（大约一页）及其带来的价值，即“价值主张”。忽略那些不区分这个领域模型的方面。展示域模型如何服务和平衡不同的兴趣。保持狭窄。尽早撰写本声明并在获得新见解时对其进行修改。

突出核心

　　领域愿景声明从广义上确定了核心领域，但它将特定核心模型元素的识别留给了个别解释的变幻莫测。除非团队中的沟通水平异常高，否则仅凭视力很难识别重点。

　　即使团队成员可能广泛了解核心领域的构成，但是不同的人不会选择相同的元素，即使是同一个人在一天之间也不会保持一致。不断过滤模型以识别关键部分的精神劳动吸收了更好地投入到设计思维上的注意力，并且需要对模型的全面了解。必须使核心域更容易看到。

　　代码的重大结构变化是识别核心域的理想方式，但它们在短期内并不总是实用的。事实上，如果没有团队缺乏的观点，很难进行如此重大的代码更改。

因此（作为突出核心的一种形式）：

　　写一个非常简短的文档（三到七个稀疏页面），描述核心域和核心元素之间的主要交互。(banq注：建议使用UML图形表示法更比文字等自然语言具有逻辑推理性，多角度视图性)

和采取/或采取（作为突出核心的另一种形式）：

　　在模型的主存储库中标记核心域的元素，而不是特别试图阐明其角色。让开发人员轻松了解核心内部或外部的内容。

　　如果蒸馏文件概述了核心领域的基本要素，那么它就是模型变化重要性的实际指标。当模型或代码更改影响蒸馏文档时，需要与其他团队成员协商。进行更改时，需要立即通知所有团队成员，并传播新版本的文档。核心之外的变化或未包含在蒸馏文件中的细节可以在没有咨询或通知的情况下整合，并且在其工作过程中将遇到其他成员。然后开发人员拥有大多数敏捷流程建议的完全自治权。

　　虽然愿景陈述和突出核心的信息和指导，但它们实际上并没有修改模型或代码本身。对通用子域进行分区会物理上删除一些分散注意力的元素。接下来，我们将介绍在结构上改变模型和设计本身的其他方法，以使核心域更加可见和易于管理。。。。

凝聚机制

　　计算有时达到复杂程度，开始使设计膨胀。“做什么”被“如何做”淹没，提供解决问题的算法的大量方法掩盖了表达问题的方法。

因此：

　　将概念上有凝聚力的机制划分为单独的轻量级框架。特别注意形式逻辑或记录良好的算法类别。公开框架的功能与意图 - 表达界面。现在，领域的其他元素可以专注于表达问题（“什么”），将解决方案的复杂性（“如何”）委托给框架。

　　分解通用子域减少了混乱，并且内聚机制用于封装复杂的操作。这留下了一个更集中的模型，更少的干扰对用户进行活动的方式没有特别的价值。但是你不可能在领域模型中寻找不是核心的所有东西。隔离核心采用直接方法在结构上标记核心域。。。

(banq注：数据库封装了数据结构和算法，向客户端只提供声明性接口：SQL，还有Java的Collection等)

隔离核心

　　模型中的元素可以部分服务于核心域，并部分地发挥支持作用。核心元素可以与通用元素紧密耦合。核心的概念凝聚力可能不强或不可见。所有这些混乱和纠缠都扼杀了核心。设计师无法清楚地看到最重要的关系，导致设计薄弱。

因此：

　　重构模型以将核心概念与支持的参与者（包括错误定义的参与者）分开，并加强核心的凝聚力，同时减少与其他代码的耦合。将所有通用或支持元素纳入其他对象并将它们放入其他包中，即使这意味着以分离高度耦合元素的方式重构模型。

(banq注：分离出Helper类就剩下被帮助者了)

总结核心

　　即使是核心领域模型通常也有如此多的细节，以至于难以传达大局。

　　当在不同模块中的子域之间存在大量交互时，必须在模块之间创建许多引用，这会破坏分区的大部分价值，或者必须间接进行交互，这使得模型模糊不清。

因此：

　　确定模型中最基本的差异化概念，并将它们分解为不同的类，抽象类或接口。设计这个抽象模型，使其表达重要组件之间的大部分交互。将此抽象整体模型放在其自己的模块中，而专门的详细实现类保留在由子域定义的自己的模块中。