DDD设计学习

之前在研究生项目中遇到的问题便是：

随着业务需求的不断改变，需要在原有项目代码中不断进行修改，导致代码不断累积。

那如何构建高质量应用，那就要遵循三大设计原则：

1.单一职责原则：一个类只负责单一的职责；

2.开放封闭原则；

3.依赖反转原则：程序之间只依赖于抽象接口，而不依赖于具体实现

坏的代码如下所示：

可见代码如下所示，调用了第三方的服务，造成了代码的不稳定性（风控）

改进后的方法，首先设计了充血模型，即类和有关方法写在一块(存钱取钱，即对于类对象属性有改动的方法)：

使用充血模型的实体对象，描述核心的业务能力(每一个实体只承担与其直接相关的属性和业务逻辑)（有可能会产生很多类造成类爆炸的问题，因此需要聚合减少类的数量）

将数据库的操作做隔离，定义接口，并定义实现类用于实现有关数据库的操作，而用户调用只需要调用api，不用管代码中的具体内容(这样如果有业务更改，如换框架操作数据库，只需要修改实现类的具体代码，而不用修改其他地方的代码，做到了隔离)。

使用仓库与工厂，封装实体持久化操作，摆脱数据库限制

构建防腐层，隔离外部服务！

即将各种业务（使用第三方api）的代码用接口封装，在最后进行直接调用，保证低耦合。同时这样也方便进行单元测试，将各种业务拆分成子业务，可以更加精准定位问题所在之处。

DDD总体设计如下所示：

总体来说，MVC架构设计的技术逻辑非常清晰，controller就是负责交互的，model就是负责业务处理诸如此类；然而业务逻辑相当不清晰，难以区分service层中各类分别是处理什么业务的；而DDD设计拥有比较清晰的业务逻辑，优先强调逻辑边界，适用于微服务的架构。

DDD以业务优先，代码架构如下所示：