DDD领域驱动设计实战-分层架构及代码目录结构

• 严格分层架构(Strict Layers Architecture)

某层只能与其直接下层耦合，即我的奴隶的奴隶，不是我的奴隶。

• 松散分层架构(Relaxed Layers Architecture)

允许任意上层与任意下层耦合。由于用户接口层和应用服务通常需要与基础设施打交道，许多系统都是该架构。

较低层有时也可与较高层耦合，但只限于采用观察者 (Observer)模式或者调停者(Mediator)模式场景。

较低层绝不能直接访问较高层。例如，在使用调停者模式时，较高层可能实现了较低层的接口，然后将实现对象作为参数传递到较低层。当较低层调用该实现时， 它并不知道实现出自何处。

1.3 分层架构演进

---

1.3.1 传统四层架构

将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层逻辑的依赖，因为它们不属业务逻辑。将一个夏杂的系统分为不同的层，每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。

传统分层架构的基础设施层位于底层，持久化和消息机制便位于该层。

这里的消息包含

• MQ消息

• SMTP

• 文本消息(SMS)

可将基础设施层中所有组件看作应用程序的低层服务，较高层与该层发生耦合以复用技术基础设施。即便如此，依然应避免核心的领域模型对象与基础设施层直接耦合。

1.3.2 改良版四层架构

传统架构的缺陷

DDD初创开发团队发现，将基础设施层放在最底层存在缺点，比如此时领域层中的一些技术实现就很困难：

• 违背分层架构的基本原则

• 难以编写测试用例

何解？

使用依赖反转设计原则：低层服务（如基础设施层）应依赖高层组件（比如用户界面层、应用层和领域层）所提供的接口。

应用依赖反转原则

• 依赖反转原则后的分层方式：基础设施层在最上方，可实现所有其他层中定义的接口

依赖反转原则真的可以支持所有层吗？

有人认为依赖反转原则中只存在两层：最上方和最下方，上层实现下层定义的抽象接口。因此上图的基础设施层将位于最上方，而用户接口层、应用层和领域层应作同层且都位于下方。对此大家可保留自己意见。

2 各层职责

=====================================================================

2.1 Interfaces（用户接口层）

---

一般包括用户接口、Web 服务等。

只处理用户显示和用户请求，不应包含领域或业务逻辑。

有人认为，既然用户接口需验证用户输入，就无可避免应该包含业务逻辑。事实上，用户接口所进行的验证和对领域模型的验证不同：对那些粗制滥造且只面向领域模型的验证行为，应该予以限制。

如果用户接口使用了领域模型中的对象，那么此时领域对象仅限于数据渲染展现。在采用这种方式时，可使用展现模型对用户接口与领域对象进行解耦。

由于用户可能是人，也可能是其他系统，有时用户接口层将采用开放主机服务的方式向外提供API。

用户接口层是应用层的直接用户。