领域驱动设计（DDD）理论与方法

• Domain为领域层（或模型层），负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心，领域模型位于这一层。

• Infrastructure层为基础设施层，向其他层提供通用的技术能力：为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件等，其中消息包含了消息中间件所发的消息、基本的电子邮件（SMTP）或者文本消息（SMS）等

但是分层架构也不是没有缺点，除了引入分层导致层之间交互带来的性能开销之外，也存在一些开发上的问题，比如：

1）容易导致分层划分不当，比如领域逻辑大量渗透到应用服务层，导致领域模型变成贫血模型，尽管有些最佳实践和其他解决方案能够解决上述问题，但也增大了新方案带来的学习成本

2）容易违反分层架构原则，比如在DDD设计中，如果领域层使用了基础设施层的实体对象持久化机制，那么基础设施层将反向引用领域层的业务对象，违反了分层架构原则。即使领域层使用基础设施层的持久化库接口Repository，领域模型仍然存在外部依赖，无法保证业务逻辑的顺利执行，也给测试开发带来了困难，理想中的领域模型应该是纯业务、基于内存运行的业务逻辑封装。

对第一个问题，可以通过DCI来解决，详见下文#DDD与DCI部分。对第二个问题可以通过依赖倒置原则(Dependency Inversion Principle,DIP)来解决，详见下文#DDD与六边形架构部分

DDD与DCI

=======

面向对象建模面临的一个棘手问题是数据边界和行为边界往往不一致。遵循模块化的思想，我们通过类将行为和其紧密耦合的数据封装在一起。但是在复杂的业务场景下，行为往往跨越多个领域对象，这样的行为如果放在某一个对象中必然会导致别的对象需要向该对象暴漏其内部状态。所以面向对象发展的后来，领域建模出现两种派别之争，一种倾向于将跨越多个领域对象的行为建模在领域服务中。如果这种做法使用过度，则会导致领域对象变成只提供一堆get方法的哑对象，这种建模结果被称之为贫血模型。而另一派则坚定地认为方法应该属于领域对象，所以所有的业务行为仍然被放在领域对象中，这样导致领域对象随着支持的业务场景变多而变成上帝类，而且类内部方法的抽象层次很难一致。另外由于行为边界很难恰当，导致对象之间数据访问关系也比较复杂，这种建模结果被称之为充血模型。

比如以字处理器中拼音检查为例，拼音检查这个行为功能放在哪里？是dictionary 还是一个全局的拼音检查器呢？无论放在哪个对象内部，都显得和这个对象内聚性不高，由此带来多个调用拼音检查行为对象之间的协作耦合，在DDD 中，可以使用领服务来实现；在SOA看来，拼音检查属于一种规则，可由规则引擎实现，通过服务整合流程和规则。

再比如银行转账，如果将转账的业务逻辑这个程序算法整合到账户Account数据模型中，因为转账涉及到其他账户和Money数据对象，那么就将因为行为操作带来的耦合带到当前账户对象中了；当然，如果程序算法可以精化细分，那么我们把它切分到几个部分，封装成几个对象的方法，但是这些方法都是无法表达算法逻辑高内聚性的琐碎小方法。

DCI架构则不同于DDD 这种有些折扣的处理方法，而是思路复位，重新考虑架构。DCI架构是James O. Coplien和Trygve Reenskaug在2009年发表的论文《Architecture: A New Vision of Object-Oriented Programming》(以下简称DCI Architecture）中引入，从OO 思想根源来深入解剖DCI 对传统面向对象的颠覆。DCI从对象数据object Data, 对象之间的协作the Collaborations between objects, 和表达需求用例中操作者角色之间的交互这三个出发点来考虑，认为数据模型data model, 角色模型role model和协作交互模型collaboration model(算法属于协作交互模型) 应该是程序语言核心关心点，应该从语言层面来关注，DCI各部分组成及含义如下：

• Data：描述系统有哪些领域概念及其之间的关系，该层专注于领域对象的确立和这些对象的生命周期管理及关系，让程序员站在对象的角度思考系统

• Context：Context通过无状态绑定role来完成业务逻辑࿰