[](()1.1 分层架构的基本原则
每层只与位于其下方的层发生耦合。
[](()1.2 分层架构的分类
- 严格分层架构(Strict Layers Architecture)
某层只能与其直接下层耦合,即我的奴隶的奴隶,不是我的奴隶。
- 松散分层架构(Relaxed Layers Architecture)
允许任意上层与任意下层耦合。由于用户接口层和应用服务通常需要与基础设施打交道,许多系统都是该架构。
较低层有时也可与较高层耦合,但只限于采用观察者 (Observer)模式或者调停者(Mediator)模式场景。
较低层绝不能直接访问较高层。例如,在使用调停者模式时,较高层可能实现了较低 Java开源项目【ali1024.coding.net/public/P7/Java/git】 层的接口,然后将实现对象作为参数传递到较低层。当较低层调用该实现时, 它并不知道实现出自何处。
[](()1.3 分层架构演进
[](()1.3.1 传统四层架构
将领域模型和业务逻辑分离出来,并减少对基础设施、用户界面甚至应用层逻辑的依赖,因为它们不属业务逻辑。将一个夏杂的系统分为不同的层,每层都应该具有良好的内聚性,并且只依赖于比其自身更低的层。
传统分层架构的基础设施层位于底层,持久化和消息机制便位于该层。
这里的消息包含
-
MQ消息
-
SMTP
-
文本消息(SMS)
可将基础设施层中所有组件看作应用程序的低层服务,较高层与该层发生耦合以复用技术基础设施。即便如此,依然应避免核心的领域模型对象与基础设施层直接耦合
。
[](()1.3.2 改良版四层架构
[](()传统架构的缺陷
DDD初创开发团队发现,将基础设施层放在最底层存在缺点,比如此时领域层中的一些技术实现就很困难:
-
违背分层架构的基本原则
-
难以编写测试用例
何解?
使用依赖反转设计原则:低层服务(如基础设施层)应依赖高层组件(比如用户界面层、应用层和领域层)所提供的接口。