贫血模型和富领域模型

1.POJO对象(Plain Old Java Object)

Plain Old Java Object(POJO)，它的本来含义是指一个常规的、不受任何框架、平台的约束和限制的Java对象。可以认为，如果一个模块定义的对象皆为POJO，那么除了依赖JDK，它不会依赖任何框架或平台。

POJO对象并非只有getter/setter的贫血对象，它的主要特征不在于它究竟定义了什么样的成员，而在于它作为一个常规的Java对象，并不依赖于除语言之外的任何框架。它的目的不是数据传输，也不是数据持久化，本质上，它是一种设计模式。

2.Java Bean

一个Java Bean类必须同时满足以下3个条件：

• 类必须是具体的、公共的；
• 具有无参构造函数；
• 为内部字段提供规范的getter/setter方法。

它们都是为支持反射访问类成员而准备的前置条件，框架使用Java Bean，看重的其实是对象携带数据的能力，可通过反射访问对象的字段值来简化代码的编写。

3.贫血模型

贫血领域模型(anemic domain model)，它违背了面向对象设计的关键原则，即“数据与行为应该封装在一起”。所谓的“血”就用来指代领域逻辑。

贫血领域模型与富领域模型，需要满足两点要求：

• 领域模型仅仅封装领域逻辑，尽可能不掺杂访问外部资源如mybatis、redis、kafka等的技术实现；
• 根据角色构造型分配职责，各司其职，共同协作。

各种“XO”

1.数据传输对象(data transfer object，DTO)

数据传输对象(data transfer object，DTO)，用于在进程间传递数据的对象，目的是减少方法调用的数量。尽可能设计粗粒度的服务，粗粒度服务可以减少服务调用的次数，从而减少不必要的网络通信，同时也能避免对分布式事务的支持。

最好将其设计为一个Java Bean，即定义为公开的类，具有默认构造函数和getter/setter方法，这样就有利于一些框架通过反射来创建与组装。还应该是一个贫血对象，因为它的目的是传输数据，没有必要定义封装逻辑的方法，但可能需要为其定义转换方法。

2.视图对象(view object，VO)

视图对象(view object，VO)也是Java Bean中的一种。当然，我们也可以沿用DTO模式。由于它主要用于后端控制器服务和前端UI之间的数据传递，这样的视图模型对象自然也属于DTO对象的范畴。

3.业务对象(business object，BO)

业务对象(business object，BO)是用来描述业务概念的语义对象。业务对象的业务逻辑恰好也是领域驱动设计关注的核心，可认为领域驱动设计建立的领域模型皆是业务对象。为避免混淆，我建议不要在领域驱动设计中使用该概念。

4.领域对象(domain object，DO)

领域对象(domain object，DO)。领域模型对象同业务对象(business object，BO)。

DO也可以认为是数据对象(data object)的简称，两者容易混淆。

5.持久化对象(persistence object，PO)

持久化对象(persistence object，PO)。只要对象需要持久化，就会成为持久化对象，这与采用什么样的建模方法、什么样的设计方法没有关系。理想的领域模型对象应该是一个POJO或POCO，不依赖于除语言之外的任何框架。

6.数据访问对象(data access object，DAO)

数据访问对象(data access object，DAO)对持久化对象进行持久化，实现数据的访问。它可以持久化领域模型对象，但对领域模型对象的边界没有任何限制。

思维导图