DDD领域驱动设计

场景

编写一个业务时按照流程进行流行 mvc结构

缺点

不易扩展、测试困难 每一个细节变化都需要修改 在DDD中称为事务脚本
想要优化需要高内聚低耦合

DDD三个原则

单一职责原则： 一个类只有一个引起他变化的原因。
开放封闭原则： 对扩展开发、对修改封闭。
依赖反转原则： 程序之间要依赖于抽象的接口，而不是具体的实现。

DDD思想改造上述场景

抽象数据存储层

a.实体充血模型，将实体以及引起实体状态变化（属性值变化）的一些方法写到一起（类中）[原来使用的是贫血模型 即POJO 只有属性 get set 没有业务 看不出来实体的业务 贫血失忆症]
b.仓库，抽出一个与变化无关的接口 例如数据库存储[未来假如将dao 换为mapper 则增加一个实现类即可]
c.工厂，实体的组装，屏蔽实体与表设计之间的不对称[多对多 关联表交给工厂]
d.防腐层，隔离第三方服务、隔离第三方工具组件 抽象出接口 返回自己的结果
e.领域服务，将业务动作抽象到一体接口 例如转账 增加 减少抽象到一块

好处

拔插思想

四层结构

在这里插入图片描述

理解实体与值对象

实体 代表具有唯一Id的领域对象 具有生命周期
值对象 代表一成不变的、本质性的业务

实体与实体之间通过id 实体与值对象之间 直接冗余进去（反范式设计）

聚合 用来确保这些领域的对象在实现共同的业务逻辑时，保证数据的一致性，每一个聚合只有一个唯一的访问入口，成为聚合根，可以理解为主键

不影响实体状态的变化 可以打破DDD 例如查询

业务领域，保证业务领域之间的边界 直接掉接口，不能直接掉业务

我的理解

DDD用于设计影响系统变动的业务

作者声明

如有问题，欢迎指正！