失血、贫血、充血与胀血模型是领域对象设计的四种形态。失血模型仅含属性，业务逻辑全在服务层；贫血模型增加行为但不依赖持久层；充血模型包含大部分业务及持久化逻辑；胀血模型将所有逻辑放入实体。文章通过 Java 代码对比了各模型实现，分析了 DDD 分层架构，并指出贫血模型因隔离持久化技术更利于维护而值得推荐。
领域模型分为 4 大类：失血模型、贫血模型、充血模型、胀血模型。这类理论都是由软件设计领域的大牛（如 Martin Fowler）提出来的，有其背景和原因。
想要理解这几个分类，先要知道**'血'指的是 Domain Object 的 Domain 层内容**。
Domain Object（领域对象）模型仅仅包含对象属性的定义和操作对象属性的getter/setter 方法，**所有的业务逻辑完全由 Business Logic 层 (业务逻辑层) 中的服务类来完成。**这种类在 java 中叫 POJO，在.NET 中叫 POCO。
优点
领域对象结构简单
缺点
肿胀的业务服务代码逻辑，难于理解和维护
无法良好的应对复杂业务逻辑和场景
Domain Object（领域对象）模型包含对象属性的定义和操作对象属性的getter/setter 方法并包含了对象的行为（例如：就像一个完整的人，具有一些属性如姓名、性别、年龄等，还具有一些能力，如走路、吃饭、恋爱等，这样才是一个完整的对象）， 但不包含依赖 Dao 层 (持久层) 的业务逻辑。这部分依赖于 Dao 层的业务逻辑将会放到Business Logic 层（业务逻辑层）中的服务类来实现，组合逻辑也由服务类负责。可以看出，贫血模型中的领域对象是不依赖于持久层的。代码架构层次结构是： Client-> Business Facade Service -> Business Logic Service(Business Logic Service 是依赖 Domain Object 的行为) -> Data Access Service
优点
层次结构清楚，各层之间单向依赖
对于只有少量业务逻辑的应用来说，使用起来非常自然
开发迅速，易于理解
缺点
Domain Object（领域对象）模型包含对象属性的定义和操作对象属性的getter/setter 方法并包含了大多数相关的业务逻辑，也包含了依赖于持久层的业务逻辑，Business Logic 层是很薄的一层，仅仅简单封装少量业务逻辑以及控制事务、权限逻辑等，不和 DAO 层打交道。所以**，使用充血模型的领域对象是依赖于持久层的。代码架构层次结构是**： Client-> Business Facade Service -> Business Logic Service -> Domain Object -> Data Access Service
优点
Business Logic 层很薄，**符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重，**只充当 Facade 的角色，不和 DAO 打交道。
缺点
Domain Object（领域对象）模型包含对象属性的定义和操作对象属性的getter/setter 方法并包含了所有相关的的业务逻辑，也包含了不想关的其它应用逻辑（如授权、事务等）。胀血模型取消了 Business Logic 层 (业务逻辑层)，只剩下 Domain Object 和 DAO 两层，在 Domain Object 的 Domain Logic 上面封装事务，授权逻辑等。
优点
缺点
下面用举一个具体的代码来说明：
Java 代码:
public class Item implements Serializable {
private Long id = null;
private int version;
private String name;
private User seller;
private String description;
private MonetaryAmount initialPrice;
private MonetaryAmount reservePrice;
private Date startDate;
private Date endDate;
private Set categorizedItems = new HashSet();
private Collection bids = new ArrayList();
private Bid successfulBid;
private ItemState state;
private User approvedBy;
private Date approvalDatetime;
private Date created = new Date();
//getter/setter 方法省略不写，避免篇幅太长
}
Java 代码:
public interface ItemDao {
public Item getItemById(Long id);
public Collection findAll();
public void updateItem(Item item);
}
ItemDao 定义持久化操作的接口，用于隔离持久化代码。
Java 代码：
public class ItemDaoHibernateImpl implements ItemDao extends HibernateDaoSupport {
public Item getItemById(Long id) {
return (Item) getHibernateTemplate().load(Item.class, id);
}
public Collection findAll() {
return (List) getHibernateTemplate().find("from Item");
}
public void updateItem(Item item) {
getHibernateTemplate().update(item);
}
}
ItemDaoHibernateImpl 完成具体的持久化工作，请注意，数据库资源的获取和释放是在 ItemDaoHibernateImpl 里面处理的，每个 DAO 方法调用之前打开 Session，DAO 方法调用之后，关闭 Session。(Session 放在 ThreadLocal 中，保证一次调用只打开关闭一次)
Java 代码：
public class ItemManager {
private ItemDao itemDao;
public void setItemDao(ItemDao itemDao) { this.itemDao = itemDao;}
public Bid loadItemById(Long id) {
itemDao.loadItemById(id);
}
public Collection listAllItems() {
return itemDao.findAll();
}
public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount,
Bid currentMaxBid, Bid currentMinBid) throws BusinessException {
if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) {
throw new BusinessException("Bid too low.");
}
// Auction is active
if ( !state.equals(ItemState.ACTIVE) )
throw new BusinessException("Auction is not active yet.");
// Auction still valid
if ( item.getEndDate().before( new Date() ) )
throw new BusinessException("Can't place new bid, auction already ended.");
// Create new Bid
Bid newBid = new Bid(bidAmount, item, bidder);
// Place bid for this Item
item.getBids().add(newBid);
itemDao.update(item); // 调用 DAO 完成持久化操作
return newBid;
}
}
事务的管理是在 ItemManger 这一层完成的，ItemManager 实现具体的业务逻辑。除了常见的和 CRUD 有关的简单逻辑之外，这里还有一个 placeBid 的逻辑，即项目的竞标。
以上是一个完整的第一种模型的示例代码。在这个示例中，placeBid，loadItemById，findAll 等等业务逻辑统统放在 ItemManager 中实现，而 Item 只有 getter/setter 方法。
下面用举一个具体的代码来说明：
Java 代码:
public class Item implements Serializable {
// 所有的属性和 getter/setter 方法同上，省略
public Bid placeBid(User bidder, MonetaryAmount bidAmount,
Bid currentMaxBid, Bid currentMinBid)
throws BusinessException {
// Check highest bid (can also be a different Strategy (pattern))
if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) {
throw new BusinessException("Bid too low.");
}
// Auction is active
if ( !state.equals(ItemState.ACTIVE) )
throw new BusinessException("Auction is not active yet.");
// Auction still valid
if ( this.getEndDate().before( new Date() ) )
throw new BusinessException("Can't place new bid, auction already ended.");
// Create new Bid
Bid newBid = new Bid(bidAmount, this, bidder);
// Place bid for this Item
this.getBids.add(newBid); // 请注意这一句，透明的进行了持久化，但是不能在这里调用 ItemDao，Item 不能对 ItemDao 产生依赖！return newBid;
}
}
**竞标这个业务逻辑被放入到 Item 中来。**请注意 this.getBids.add(newBid); 如果没有 Hibernate 或者 JDO 这种 O/R Mapping 的支持，我们是无法实现这种透明的持久化行为的。但是请注意，Item 里面不能去调用 ItemDAO，对 ItemDAO 产生依赖！
Java 代码:
public interface ItemDao {
public Item getItemById(Long id);
public Collection findAll();
public void updateItem(Item item);
}
ItemDao 定义持久化操作的接口，用于隔离持久化代码。
Java 代码:
public class ItemDaoHibernateImpl implements ItemDao extends HibernateDaoSupport {
public Item getItemById(Long id) {
return (Item) getHibernateTemplate().load(Item.class, id);
}
public Collection findAll() {
return (List) getHibernateTemplate().find("from Item");
}
public void updateItem(Item item) {
getHibernateTemplate().update(item);
}
}
ItemDaoHibernateImpl 完成具体的持久化工作
Java 代码:
public class ItemManager {
private ItemDao itemDao;
public void setItemDao(ItemDao itemDao) { this.itemDao = itemDao;}
public Bid loadItemById(Long id) {
itemDao.loadItemById(id);
}
public Collection listAllItems() {
return itemDao.findAll();
}
public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount,
Bid currentMaxBid, Bid currentMinBid) throws BusinessException {
item.placeBid(bidder, bidAmount, currentMaxBid, currentMinBid);
itemDao.update(item); // 必须显式的调用 DAO，保持持久化
}
}
下面用举一个具体的代码来说明：
Java 代码:
public interface ItemDao {
public Item getItemById(Long id);
public Collection findAll();
public void updateItem(Item item);
}
ItemDao 定义持久化操作的接口，用于隔离持久化代码。
Java 代码:
public class ItemDaoHibernateImpl implements ItemDao extends HibernateDaoSupport {
public Item getItemById(Long id) {
return (Item) getHibernateTemplate().load(Item.class, id);
}
public Collection findAll() {
return (List) getHibernateTemplate().find("from Item");
}
public void updateItem(Item item) {
getHibernateTemplate().update(item);
}
}
ItemDaoHibernateImpl 完成具体的持久化工作
Java 代码:
public class Item implements Serializable {
//所有的属性和 getter/setter 方法都省略
private static ItemDao itemDao;
public void setItemDao(ItemDao itemDao) {this.itemDao = itemDao;}
public static Item loadItemById(Long id) {
return (Item) itemDao.loadItemById(id);
}
public static Collection findAll() {
return (List) itemDao.findAll();
}
public Bid placeBid(User bidder, MonetaryAmount bidAmount,
Bid currentMaxBid, Bid currentMinBid)
throws BusinessException {
// Check highest bid (can also be a different Strategy (pattern))
if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) {
throw new BusinessException("Bid too low.");
}
// Auction is active
if ( !state.equals(ItemState.ACTIVE) )
throw new BusinessException("Auction is not active yet.");
// Auction still valid
if ( this.getEndDate().before( new Date() ) )
throw new BusinessException("Can't place new bid, auction already ended.");
// Create new Bid
Bid newBid = new Bid(bidAmount, this, bidder);
// Place bid for this Item
this.addBid(newBid);
itemDao.update(this); // 调用 DAO 进行显式持久化
return newBid;
}
}
它包括用户接口层、应用层、领域层和基础层，分层架构各层的职责边界非常清晰，又能有条不紊地分层协作。
分层架构的一个重要原则是每层只能与位于其下方的层发生耦合。
分层架构可以简单分为两种，即严格分层架构和松散分层架构。在严格分层架构中，某层只能与位于其直接下方的层发生耦合，而在松散分层架构中，则允许某层与它的任意下方层发生耦合。
分层架构的优点，Martin Fowler 在《Patterns of Enterprise Application Architecture》一书中给出了答案：
**适当的分层体系结构将开发层面进行隔离，这些层不受其他层的更改的影响，从而使重构更加容易。**划分任务并定义单独的层是架构师面临的挑战。当需求很好地适应了模式时，这些层将易于解耦或分层开发。
使用场景：
现在，我们来看一下，按照 DDD 分层架构模型设计出来的微服务代码模型到底长什么样子呢？
其实，DDD 并没有给出标准的代码模型，不同的人可能会有不同理解。下面要说的这个微服务代码模型是我经过思考和实践后建立起来的，主要考虑的是微服务的边界、分层以及架构演进。
微服务一级目录结构
**微服务一级目录是按照 DDD 分层架构的分层职责来定义的。**从下面这张图中，我们可以看到，在代码模型里分别为用户接口层、应用层、领域层和基础层，建立了 interfaces、application、domain 和 infrastructure 四个一级代码目录。
这些目录的职能是这样的。
下面具体说明一下领域层的代码目录结构
**Domain 是由一个或多个聚合包构成，共同实现领域模型的核心业务逻辑。**聚合内的代码模型是标准和统一的，包括：entity、event、repository 和 service 四个子目录。
特别说明：按照 DDD 分层架构，仓储实现本应该属于基础层代码，但为了在微服务架构演进时，保证代码拆分和重组的便利性，把聚合仓储实现的代码放到了聚合包内。这样，如果需求或者设计发生变化导致聚合需要拆分或重组时，我们就可以将包括核心业务逻辑和仓储代码的聚合包整体迁移，轻松实现微服务架构演进。
在这四种模型当中，失血模型和胀血模型应该是不被提倡的。而贫血模型和充血模型从技术上来说，都是可行的。但是我个人仍然主张使用贫血模型。其理由：
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online