DDD（领域驱动设计）分享（2/2）

一、概述

DDD的系统架构有很多，常见的有分层架构、洋葱架构、六边形架构等，看起来像是多个不同的设计，但是他们的核心思想其实都差不多：职责分明、高内聚低耦合。比如洋葱架构中最内层的最小原是实体模型，表示实体对外部的依赖最小基本不依赖其他层，同样的在分层架构中的领域层也是这样的思路，领域层中实体只负责自己独立的业务逻辑，而整体的业务实现和事务等都是领域服务通过编排领域实体来实现的。

二、分层架构

DDD的分层架构遵循一个原则：每层只能与位于下方的直接下层发生耦合，而不能直接同层依赖或者向上依赖上层。由于层间松散的耦合关系，使得我们可以专注于本层的设计，而不必关心其他层的设计，也不必担心当前层的设计会影响其它层。一般来说通常分为四层：用户接口层、应用层、领域层、基础设施层。

1.用户接口层的主要职责是提供接口给前端进行调用，完成特定的产品功能，向下依赖应用层。

2.应用层主要是负责接收用户接口层参数，然后进行逻辑拆分，可能一个很复杂的功能需要多个领域共同完成，应用层需要根据实际情况对领域层进行编排，最后根据多个领域的数据组合成最终结果。与此同时，还要负责总的容错处理。

3.领域层主要专注于领域内部的逻辑，保证自己领域内部逻辑自洽，同时要处理领域内部的本地事务行为。实体主要负责核心的业务逻辑，而领域服务主要用来编排实体。

4.基础设施层主要负责一些独立的基础功能，比如数据存储，上层完全不用关心数据是如何进行持久化的，是用Mysql还是ES等，基础设施层只会暴露一个统一的接口表明自己有哪些能力即可。

分层架构看起来和传统的MVC三层架构有些相似，但是仔细探索会发现，DDD的分层架构更加细致，更加强调高内聚低耦合，永远都是向下的单向一级依赖关系，而且每层负责独立的功能，相互之间没有重叠。传统的三层架构可拓展性较差，一次功能迭代就可能导致整体的重构，而DDD中松耦合的分层架构，相对来说比较可控，每层的改动对其他层的影响较小，拓展性更高，更加适用于现在敏捷开发的模式，每次迭代都能快速完成。