DDD的演进

演进领域驱动架构的着手点：

1 避免领域模型出现贫血模型

2 保证领域模型的纯粹性

 

避免贫血的领域模型

 

经典三层架构中

1 领域逻辑 在 业务逻辑层的service对象中

2 反映了领域概念的 领域对象 被定义为Java Bean 此 Java Bean未包含任何领域逻辑 被放在 数据访问层

3 DAO 对象仅负责与数据库的交互，并实现领域对象到数据表的 CRUD（增删改查）操作

 

​

 

面向对象的设计原则：

数据与行为应该封装在一起

 

贫血对象：

Java Bean 由于仅包含了访问私有字段的 get 和 set 方法。

 

贫血对象导致的问题：

不具备对象的丰富表达能力，当业务逻辑变得复杂时，在表达领域模型方面就会变得“力不从心”，无法有效应对重用与变化，且可能导致臃肿的“上帝类”。

贫血模型带来的问题在战术设计中深入解释

 

结论：

在面向对象设计背景下，当我们面对相对复杂的业务逻辑时，应避免设计出贫血模型

 

如何避免 贫血模型：

合理地将操作数据的行为分配给这些领域模型对象（Domain Model）

领域模型对象包含了领域逻辑，就需要从数据访问层转移到业务逻辑层。

 

DAOs 对象需要操作这些领域模型对象，使得处于数据访问层的 DAOs 对象 必须依赖 领域层的领域模型对象

避免贫血的领域模型，就不可能避免底层的数据访问层对业务逻辑层的依赖。

 

​

 

保证领域模型的纯粹性

 

加粗的两条依赖线可以清晰地看到领域层与基础设施层之间产生了“双向依赖”

两个层次的紧耦合

领域模型变得不再纯粹

根因：

高层直接依赖了低层，去掉右侧 Services 指向 DAOs 的依赖

 

实现逻辑是容易变化 抽象不易改变

 

解决：

改进设计的方式是对 DAOs 进行抽象，然后利用依赖注入对数据访问的实现逻辑进行注入

​

 

抽象层应该放在哪？

抽象的资源库接口代表了领域行为，应该放在领域层

实现资源库接口的数据库持久化，需要调用诸如 MyBatis 这样的第三方框架，属于技术实现，应该放在基础设施层

​

 

抽象的 Repositories 被搬迁至领域层，图中的领域层就不再依赖任何其他层次的组件或类，成为一个纯粹的领域模型。我们的演进正逐步迈向整洁架构！

 

用户展现层的变迁

前后端分离的架构思想，将用户展现层彻底分离出去，形成一个完全松耦合的前端层。

 

​

 

缺点：

基础设施层在这里出现了两次，但同时也充分说明了基础设施层的命名存在不足

架构也凸显了分层架构在表现力方面的缺陷。

 

引入应用层

 

领域驱动设计要求应用层“不包含业务逻辑”，但对外它却提供了一个一致的体现业务用例的接口。

取代 接口层（Controller 以及 Iface） 与封装了 Entity 与 Value Object 的 Aggregate、Services 以及抽象的 Repositories 接口协作。

​

 

基础设施层（controller Iface）的本质：

 

基础设施层要做的事情不正是封装对外部系统或资源的访问

对业务的支撑，提供了与业务逻辑无关的基础功能实现。