领域驱动设计-软件核心复杂性应对之道：第四章

第二部分 模型驱动设计的构造块

设计原则：职责驱动设计

第四章 分离领域

​ 在软件中，专门用于解决领域问题的那部分通常只占整个软件系统的很小一部分，这与其重要性远远不成比例。要想实现最佳的设计构思，就得去研究模型中的元素并且将它们视为一个系统。绝不能像在夜空中辨认星座一样，勉强把领域对象从许多对象中挑选出来。我们需要将领域对象与系统中的其他功能分离，这样就能够避免将领域概念和其他只与软件技术相关的概念相混淆，也不会把领域和整个软件混为一谈。

4.1 模式：layer architecture

软件程序需要通过设计和编码来执行许多不同类型的任务。它们接收用户输入，执行业务逻辑，访问数据库，进行网络通信，向用户显示信息，等等。因此程序中每个功能都可能需要大量的代码来实现。

基本原则：层中的任何元素仅依赖于本层的其他元素或其下层的元素。向上的通信必须通过间接的传递机制进行

层介绍	层说明
用户界面层（表示层）	负责向用户显示信息和解释用户指令。这里指的用户可以使另一个计算机系统，不一定是使用用户界面的人
应用层	定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题，这一层所负责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者只是，而只为下一层中的领域对象协调任务，分配公众，使它们互相协作。它没有反应业务情况的状态，但是却可以具有另外一种状态，为用户或程序显示某个任务的进度。
领域层（模型层）	负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反应业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心
基础设施层	为上面各层提供通用的技术能力：为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件，等等。基础设施层还能通过架构框架来支持四个层次间的交互模式

给复杂的应用程序划分层次。在每一层内分别进行设计，使其具有内聚性并且只依赖于它的下层。采用标准的架构模式，只与上层进行松散连接。将所有与模型相关的代码放在一个层中，并把它与用户界面层、应用层以及基础设施层的代码分开。领域对象应该将重点放在如何表达领域模型上，而不需要考虑自己的显示和存储问题，也无需管理应用任务等内容。这使得模型的含义足够丰富，结构足够清晰，可以捕捉到基本的业务知识，并有效地使用这些知识。

1. 将各层关联起来

各层之间是松散连接的，层与层的依赖关系只能是单向的。上层可以直接使用或操作下层元素，方法是通过调用下层元素的公共接口，保持对下层元素的引用（至少是暂时的）以及采用常规的交互手段、而如果下层元素需要与上层元素进行通信（不只是回应直接查询），则需要采用另一种通信机制，使用架构模式来连接上下层，比如回调模式或观察者模式。

案例：消息发生接口放在基础设施层（电子邮件发送，传真发送，其他等等）

2. 架构框架

最好的架构框架既能解决复杂技术问题，也能让领域开发人员集中精力去表达模型，而不考虑其他问题。然而使用框架很容易为项目制造障碍；要么是设定了太多的假设，影响开发进度。

当使用框架时，项目团队应该明确其使用目的：建立一种可以表达领域模型的实现并且用它来解决重要问题。项目团队应该明确其使用目的：建立一种可以表达领域模型的实现并且用它来解决重要问题。

4.2 模型属于领域层

"领域层"是领域模型以及所有与其直接相关的设计元素的表现，它由业务逻辑的设计和实现组成。

4.3 反模式：the smart ui

项目团队常犯的错误是采用一种复杂的设计方法，却无法保证项目从头到尾始终使用它。另一种常见的也是代价高昂的错误则是为项目构建一种复杂的基础设施，并使用顶级的工具，这样的项目根本不需要他们