DDD思想与入门

1.贫血模型和充血模型

贫血模型：

• 定义对象的简单的属性值，没有业务逻辑上的方法

充血模型

• 定义属性的同时也会定义方法，可以通过某些方式直接得到属性值，也可以在对象中嵌入方法直接创建出一个具有属性值的对象。

Java业务中贫血模型为传统的Java Bean，即只有get和set方法没有对应的业务方法。

2.传统的三层结构有什么问题？（@Controller、@Service和@Repository）

数据库的表结构可能是面向对象的，满足NF范式。但是

• 业务处理中从实体类获取属性值破坏其封装。
• 业务流程依赖于ServiceImpl对象（扮演一般所说的manager的角色），导致业务迭代时间一长，实现类中会有很大一坨完全面向过程的代码逻辑，长此以往导致屎山。
• Service层的业务代码过于冗长，不加注释的情况下难以快速理解，影响可读性。
• 业务文档需要对每一个功能点详细说明，难以直观用关系图理解。

3.为什么大家都在用贫血模型？

• 贫血模型只承载数据，开发灵活，设计门槛低，从数据库中取出数据即可快速实现业务方法
• 充血模型设计难，需要充分理解业务，梳理实体关系和实体属性，构建UML图
• 充血模型开发成本高，时间周期长
• 采用DDD需要一整套架构调整，很难让所有开发测试人员快速理解

4.DDD架构

 

基于传统的三层模型，实际开发中依旧可以将Controller层视为UI层来完成对前端调用接口的结果返回。我们将原来的Service层拆解为应用层和领域层，首先要保证的是将软件最重要的资产——业务规则分离出来，抽象在领域层，并确保这些代码是领域模型的正确实现。

具体案例参见：https://www.cnblogs.com/baihmpgy/p/10760324.html

对于一个装修设计预约平台，通过边界分析，抽离出所有的实体、关系和属性，绘制UML图。

实际定义对象中，领域模型在实现上表现为两类：（1）实体（Entity）：这个领域模型有特定的标识，但是其内部状态会随着一序列的事件（对应业务规则的执行）发生变化，我们把这类模型的实现称为实体；（2）值对象（Value Object）：这个领域模型由属性来定义，实例创建后不会发生变更，变更也意味着重新创建一个实例，我们把这类模型的实现称为值对象。

• 领域层对上对下，交换的对象都应该是领域模型。
• 模型的父子关系或者一对N关系，我们在持久化层进行分解，然后使用工厂模式或者构造方法生产对象。
• 应用层主要负责对领域模型业务方法进行组装实现业务流程，通过领域层的抽象，可以减少大量应用层的冗余代码。

总的来说，DDD的目的在于在大型的、业务复杂的、迭代频繁的、微服务系统中，将业务逻辑高度抽象出一个领域层。领域层的类高度内聚且彼此之间低耦合，具体表现了业务中泛化程度高且极少变动的实体与关系。对于长期大型的项目来说DDD是必须考虑的思想，但是实际工作中要权衡开发成本和项目定位，不可盲目的使用DDD。