领域模型中的充血模型

本文来源领域模型中的充血模型

本篇笑点

我要从甲方跳到乙方公司了。
被我领导知道了

你得知道这篇讲的些什么

本文 1229 字，阅读可能需要 2 分 23 秒

与贫血模型不一样的充血模型

说明

继续上一篇 回头看领域模型中的贫血模型继续来看一下不一样的充血模型。

充血模型

充血模型和贫血模型差不多，所不同的就是如何划分业务逻辑，即认为，绝大多业务逻辑都应该被放在 domain object 里面(包括持久化逻辑)，而 Service 层应该是很薄的一层，仅仅封装事务和少量逻辑，不和 DAO 层打交道。

在贫血模型中，数据和业务逻辑被分割到不同的类中。充血模型（Rich Domain Model）正好相反，数据和对应的业务逻辑被封装到同一个类中。因此，这种充血模型满足面向对象的封装特性，是典型的面向对象编程风格。

包结构

充血模型的实现一般包括如下包：

代码实现

先看 model 包的两个类，Account 和 TransferTransaction 对象，分别代表帐户和一次转账事务。由于它们不包含业务逻辑，就是一个普通的 Java Bean，下面的代码省略了 get 和 set 方法。

/**
 * 账户
 **/
public class Account {  
    private String accountId;  
    private BigDecimal balance;  
  
    public Account() {}  
    public Account(String accountId, BigDecimal balance) {  
        this.accountId = accountId;  
        this.balance = balance;  
    }  
    // getter and setter ....  
  
} 

/**
 * 转账
 **/
public class TransferTransaction {  
    private Date timestamp;  
    private String fromAccountId;  
    private String toAccountId;  
    private BigDecimal amount;  
  
    public TransferTransaction() {}  
  
    public TransferTransaction(String fromAccountId, String toAccountId, BigDecimal amount, Date timestamp) {  
        this.fromAccountId = fromAccountId;  
        this.toAccountId = toAccountId;  
        this.amount = amount;  
        this.timestamp = timestamp;  
    }  
  
    // getter and setter ....

/**  
  * 转账逻辑  
  * @param fromAccountId 转账人  
  * @param toAccountId 收账人  
  * @param amount 金额  
  * @return  
  * @throws AccountNotExistedException  
  * @throws AccountUnderflowException  
  */
 public TransferTransaction transfer(String fromAccountId, String toAccountId,  
  BigDecimal amount) throws AccountNotExistedException, AccountUnderflowException {  
    Validate.isTrue(0 < amount.compareTo(BigDecimal.ZERO));  
      //业务逻辑略...
  
	  // 调用DAO进行显式持久化
	  return new TransferTransactionDAO().create(fromAccountId, toAccountId, amount);  
 }  
} 

发现没有 在这种模型中，所有的业务逻辑全部都在 TransferTransaction 中，事务管理也在 TransferTransaction 中实现。

这种模型的优点：
1、更加符合 OO 的原则
2、Service 层很薄，只充当 Facade 的角色，不和 DAO 打交道。

缺点也很明显
1、当 model 中包含了数据持久化的逻辑，实例化的时候可能会有很大麻烦，拿到了太多不一定需要的关联 model。

总结

所谓充血模型的思想 无非是要就是要大家不要盲目写代码不要盲目的一撸到底 要从全局设计出发 设计清楚了再开工

附言

本篇如有错误，请及时指出，马上修改。

非常非常重要的事情

本文首发于【黑壳博客】，文章持续更新，可以微信搜索【黑壳博客】点个关注 文章第一时间阅读。