大约4年前，2017年底的时候，那时刚开始工作实习，武哥让我了解了解DDD，写了这篇Blog：【架构设计 领域驱动开发 一】三层VSDDD，当时打算好好了解了解的，无奈水平不够，对这些概念也是一知半解的，所以了解也不深入，见解也不一定正确，工作4年多了，再次学习和比较下MVC和DDD吧。
概念和代码组织区别
什么是贫血MVC模型开发？什么是DDD充血模型开发？
MVC贫血模型开发模式
MVC 三层架构中的 M 表示 Model，V 表示 View，C 表示 Controller。它将整个项目分为三层：展示层、逻辑层、数据层。我们一般做业务逻辑开发一般是前后端分离的，所以对于我们后端程序员来说，类似这样的结构更通用：后端分为Repository 层、Service 层、Controller 层。其中，Repository 层负责数据访问，Service 层负责业务逻辑，Controller 层负责暴露接口。一个简单例子：
// Controller+VO(View Object) // public class UserController { private UserService userService; //通过构造函数或者IOC框架注入 public UserVo getUserById(Long userId) { UserBo userBo = userService.getUserById(userId); UserVo userVo = [...convert userBo to userVo...]; return userVo; } } public class UserVo {//省略其他属性、get/set/construct方法 private Long id; private String name; private String cellphone; } // Service+BO(Business Object) // public class UserService { private UserRepository userRepository; //通过构造函数或者IOC框架注入 public UserBo getUserById(Long userId) { UserEntity userEntity = userRepository.getUserById(userId); UserBo userBo = [...convert userEntity to userBo...]; return userBo; } } public class UserBo {//省略其他属性、get/set/construct方法 private Long id; private String name; private String cellphone; } // Repository+Entity // public class UserRepository { public UserEntity getUserById(Long userId) { //... } } public class UserEntity {//省略其他属性、get/set/construct方法 private Long id; private String name; private String cellphone; }
我们平时开发 Web 后端项目的时候，基本上都是这么组织代码的。其中，UserEntity 和 UserRepository 组成了数据访问层，UserBo 和 UserService 组成了业务逻辑层，UserVo 和 UserController 在这里属于接口层
UserBo 是一个纯粹的数据结构，只包含数据，不包含任何业务逻辑。业务逻辑集中在 UserService 中。我们通过 UserService 来操作 UserBo。换句话说，Service 层的数据和业务逻辑，被分割为 BO 和 Service 两个类中。像 UserBo 这样，只包含数据，不包含业务逻辑的类，就叫作贫血模型（Anemic Domain Model）。同理，UserEntity、UserVo 都是基于贫血模型设计的。这种贫血模型将数据与操作分离，破坏了面向对象的封装特性，是一种典型的面向过程的编程风格
DDD充血模型开发模式
在贫血模型中，数据和业务逻辑被分割到不同的类中。充血模型（Rich Domain Model）正好相反，数据和对应的业务逻辑被封装到同一个类中。因此，这种充血模型满足面向对象的封装特性，是典型的面向对象编程风格。而领域驱动设计，即 DDD，主要是用来指导如何解耦业务系统，划分业务模块，定义业务领域模型及其交互。
实际上，基于充血模型的 DDD 开发模式实现的代码，也是按照 MVC 三层架构分层的。Controller 层还是负责暴露接口，Repository 层还是负责数据存取，Service 层负责核心业务逻辑。它跟基于贫血模型的传统开发模式的区别主要在 Service 层：
- 在基于贫血模型的传统开发模式中，Service 层包含 Service 类和 BO 类两部分，BO 是贫血模型，只包含数据，不包含具体的业务逻辑。业务逻辑集中在 Service 类中
- 在基于充血模型的 DDD 开发模式中，Service 层包含 Service 类和 Domain 类两部分。Domain 就相当于贫血模型中的 BO。不过，Domain 与 BO 的区别在于它是基于充血模型开发的，既包含数据，也包含业务逻辑。而 Service 类变得非常单薄
总结一下的话就是，基于贫血模型的传统的开发模式，重 Service 轻 BO；基于充血模型的 DDD 开发模式，轻 Service 重 Domain。
业务应用场景区别
这一part我们主要了解下贫血模式为啥流行，什么情况下用充血模式好。
贫血模式流行的原因
基于贫血模型的传统开发模式，将数据与业务逻辑分离，违反了 OOP 的封装特性，实际上是一种面向过程的编程风格。这种风格一个问题就是不能提供面向对象的封装特性，比如，数据和操作分离之后，数据本身的操作就不受限制了。任何代码都可以随意修改数据。但是，现在几乎所有的 Web 项目，都是基于这种贫血模型的开发模式。这是为什么呢？
- 大部分情况下，我们开发的系统业务可能都比较简单，简单到就是基于 SQL 的 CRUD 操作，所以，根本不需要动脑子精心设计充血模型，贫血模型就足以应付这种简单业务的开发工作。除此之外，因为业务比较简单，即便我们使用充血模型，那模型本身包含的业务逻辑也并不会很多，设计出来的领域模型也会比较单薄，跟贫血模型差不多，没有太大意义
- 充血模型的设计要比贫血模型更加有难度。因为充血模型是一种面向对象的编程风格。我们从一开始就要设计好针对数据要暴露哪些操作，定义哪些业务逻辑。而不是像贫血模型那样，我们只需要定义数据，之后有什么功能开发需求，我们就在 Service 层定义什么操作，不需要事先做太多设计。前边的Blog说过：【Java设计模式 面向对象设计思想】二 再谈面向对象和面向过程，面向过程实际上更符合人脑的思考方式
- 思维已固化，转型有成本。基于贫血模型的传统开发模式经历了这么多年，已经深得人心、习以为常。在没有遇到开发痛点的情况下，我们是不愿意也没必要做这件事情的。
落实到开发模式，我们平时的开发，大部分都是 SQL 驱动（SQL-Driven）的开发模式。我们接到一个后端接口的开发需求的时候，就去看接口需要的数据对应到数据库中，需要哪张表或者哪几张表，然后思考如何编写 SQL 语句来获取数据。之后就是定义 Entity、BO、VO，然后模板式地往对应的 Repository、Service、Controller 类中添加代码，基于以上原因，贫血模型才越来越留行。
什么情况下使用充血模式
基于贫血模型的传统的开发模式，比较适合业务比较简单的系统开发。当业务逐步复杂，新来的同事不知道老逻辑，直接在service中增加自己需要的功能，新增的功能满天飞在service中，这样的开发方式会让代码越来越混乱，复用度低，最终导致无法维护。
相反，基于充血模型的 DDD 开发模式，更适合业务复杂的系统开发，越复杂的系统，对代码的复用性、易维护性要求就越高，我们就越应该花更多的时间和精力在前期设计上。而基于充血模型的 DDD 开发模式，正好需要我们前期做大量的业务调研、领域模型设计，所以它更加适合这种复杂系统的开发，新来的同事一看Domain的设计就能大致清楚当前有哪些业务功能集中在业务层BO。
贫血VS充血实战演练
假设我们要实现一个虚拟钱包，包含五部分功能，充值、提现、转账、查询余额、查询交易流水，充值、提现、转账、查询余额都是针对金额进行操作，交易流水包含如下信息：
贫血模式-虚拟钱包
老CRUD业务BOY的代码一定是这样的，其中，Controller 和 VO 负责暴露接口，具体的代码实现如下所示。Controller 中，接口实现比较简单，主要就是调用 Service 的方法
// Controller+VO(View Object) // public class VirtualWalletController { // 通过构造函数或者IOC框架注入 private VirtualWalletService virtualWalletService; public BigDecimal getBalance(Long walletId) { ... } //查询余额 public void debit(Long walletId, BigDecimal amount) { ... } //出账-提现 public void credit(Long walletId, BigDecimal amount) { ... } //入账-充值 public void transfer(Long fromWalletId, Long toWalletId, BigDecimal amount) { ...} //转账 //省略查询transaction的接口-查询交易流水 }
Service 和 BO 负责核心业务逻辑，Repository 和 Entity 负责数据存取。Repository 这一层的代码实现比较简单，就省略掉了。
public class VirtualWalletBo {//省略getter/setter/constructor方法 private Long id; private Long createTime; private BigDecimal balance; //金额 } public Enum TransactionType { DEBIT, CREDIT, TRANSFER; } public class VirtualWalletService { // 通过构造函数或者IOC框架注入 private VirtualWalletRepository walletRepo; private VirtualWalletTransactionRepository transactionRepo; public VirtualWalletBo getVirtualWallet(Long walletId) { VirtualWalletEntity walletEntity = walletRepo.getWalletEntity(walletId); VirtualWalletBo walletBo = convert(walletEntity); return walletBo; } public BigDecimal getBalance(Long walletId) { return walletRepo.getBalance(walletId); } @Transactional public void debit(Long walletId, BigDecimal amount) { VirtualWalletEntity walletEntity = walletRepo.getWalletEntity(walletId); BigDecimal balance = walletEntity.getBalance(); if (balance.compareTo(amount) < 0) { throw new NoSufficientBalanceException(...); } VirtualWalletTransactionEntity transactionEntity = new VirtualWalletTransactionEntity(); transactionEntity.setAmount(amount); transactionEntity.setCreateTime(System.currentTimeMillis()); transactionEntity.setType(TransactionType.DEBIT); transactionEntity.setFromWalletId(walletId); transactionRepo.saveTransaction(transactionEntity); walletRepo.updateBalance(walletId, balance.subtract(amount)); } @Transactional public void credit(Long walletId, BigDecimal amount) { VirtualWalletTransactionEntity transactionEntity = new VirtualWalletTransactionEntity(); transactionEntity.setAmount(amount); transactionEntity.setCreateTime(System.currentTimeMillis()); transactionEntity.setType(TransactionType.CREDIT); transactionEntity.setFromWalletId(walletId); transactionRepo.saveTransaction(transactionEntity); VirtualWalletEntity walletEntity = walletRepo.getWalletEntity(walletId); BigDecimal balance = walletEntity.getBalance(); walletRepo.updateBalance(walletId, balance.add(amount)); } @Transactional public void transfer(Long fromWalletId, Long toWalletId, BigDecimal amount) { VirtualWalletTransactionEntity transactionEntity = new VirtualWalletTransactionEntity(); transactionEntity.setAmount(amount); transactionEntity.setCreateTime(System.currentTimeMillis()); transactionEntity.setType(TransactionType.TRANSFER); transactionEntity.setFromWalletId(fromWalletId); transactionEntity.setToWalletId(toWalletId); transactionRepo.saveTransaction(transactionEntity); debit(fromWalletId, amount); credit(toWalletId, amount); } }
充血模式-虚拟钱包
基于充血模型的 DDD 开发模式，跟基于贫血模型的传统开发模式的主要区别就在 Service 层，Controller 层和 Repository 层的代码基本上相同。重点看一下，Service 层按照基于充血模型的 DDD 开发模式该如何来实现，我们把虚拟钱包 VirtualWallet 类设计成一个充血的 Domain 领域模型，并且将原来在 Service 类中的部分业务逻辑移动到 VirtualWallet 类中，让 Service 类的实现依赖 VirtualWallet 类
// Domain领域模型(充血模型) public class VirtualWallet { private Long id; private Long createTime = System.currentTimeMillis();; private BigDecimal balance = BigDecimal.ZERO; public VirtualWallet(Long preAllocatedId) { this.id = preAllocatedId; } public BigDecimal balance() { return this.balance; } public void debit(BigDecimal amount) { if (this.balance.compareTo(amount) < 0) { throw new InsufficientBalanceException(...); } this.balance = this.balance.subtract(amount); } public void credit(BigDecimal amount) { if (amount.compareTo(BigDecimal.ZERO) < 0) { throw new InvalidAmountException(...); } this.balance = this.balance.add(amount); } }
Service层就不包含业务模型的相关代码了，它只是将获取到的Entity对象转为领域模型，由领域模型进行数值更新后再写回到数据库中
// Domain领域模型(充血模型) public class VirtualWalletService { // 通过构造函数或者IOC框架注入 private VirtualWalletRepository walletRepo; private VirtualWalletTransactionRepository transactionRepo; public VirtualWallet getVirtualWallet(Long walletId) { VirtualWalletEntity walletEntity = walletRepo.getWalletEntity(walletId); VirtualWallet wallet = convert(walletEntity); return wallet; } public BigDecimal getBalance(Long walletId) { return walletRepo.getBalance(walletId); } @Transactional public void debit(Long walletId, BigDecimal amount) { VirtualWalletEntity walletEntity = walletRepo.getWalletEntity(walletId); VirtualWallet wallet = convert(walletEntity); wallet.debit(amount); VirtualWalletTransactionEntity transactionEntity = new VirtualWalletTransactionEntity(); transactionEntity.setAmount(amount); transactionEntity.setCreateTime(System.currentTimeMillis()); transactionEntity.setType(TransactionType.DEBIT); transactionEntity.setFromWalletId(walletId); transactionRepo.saveTransaction(transactionEntity); walletRepo.updateBalance(walletId, wallet.balance()); } @Transactional public void credit(Long walletId, BigDecimal amount) { VirtualWalletEntity walletEntity = walletRepo.getWalletEntity(walletId); VirtualWallet wallet = convert(walletEntity); wallet.credit(amount); VirtualWalletTransactionEntity transactionEntity = new VirtualWalletTransactionEntity(); transactionEntity.setAmount(amount); transactionEntity.setCreateTime(System.currentTimeMillis()); transactionEntity.setType(TransactionType.CREDIT); transactionEntity.setFromWalletId(walletId); transactionRepo.saveTransaction(transactionEntity); walletRepo.updateBalance(walletId, wallet.balance()); } @Transactional public void transfer(Long fromWalletId, Long toWalletId, BigDecimal amount) { //...跟基于贫血模型的传统开发模式的代码一样... } }
领域模型 VirtualWallet 类很单薄，包含的业务逻辑很简单。相对于原来的贫血模型的设计思路，这种充血模型的设计思路，貌似并没有太大优势。这也是大部分业务系统都使用基于贫血模型开发的原因。不过，如果虚拟钱包系统需要支持更复杂的业务逻辑，那充血模型的优势就显现出来了。比如，我们要支持透支一定额度和冻结部分余额的功能。这个时候，我们重新来看一下 VirtualWallet 类的实现代码
public class VirtualWallet { private Long id; private Long createTime = System.currentTimeMillis();; private BigDecimal balance = BigDecimal.ZERO; // 透支 private boolean isAllowedOverdraft = true; private BigDecimal overdraftAmount = BigDecimal.ZERO; // 冻结 private BigDecimal frozenAmount = BigDecimal.ZERO; public VirtualWallet(Long preAllocatedId) { this.id = preAllocatedId; } // 冻结操作 public void freeze(BigDecimal amount) { ... } public void unfreeze(BigDecimal amount) { ...} // 透支操作 public void increaseOverdraftAmount(BigDecimal amount) { ... } public void decreaseOverdraftAmount(BigDecimal amount) { ... } public void closeOverdraft() { ... } public void openOverdraft() { ... } public BigDecimal balance() { return this.balance; } public BigDecimal getAvaliableBalance() { BigDecimal totalAvaliableBalance = this.balance.subtract(this.frozenAmount); if (isAllowedOverdraft) { totalAvaliableBalance += this.overdraftAmount; } return totalAvaliableBalance; } public void debit(BigDecimal amount) { BigDecimal totalAvaliableBalance = getAvaliableBalance(); if (totoalAvaliableBalance.compareTo(amount) < 0) { throw new InsufficientBalanceException(...); } this.balance = this.balance.subtract(amount); } public void credit(BigDecimal amount) { if (amount.compareTo(BigDecimal.ZERO) < 0) { throw new InvalidAmountException(...); } this.balance = this.balance.add(amount); } }
领域模型 VirtualWallet 类添加了简单的冻结和透支逻辑之后，功能看起来就丰富了很多，代码也没那么单薄了。如果功能继续演进，我们可以增加更加细化的冻结策略、透支策略、支持钱包账号（VirtualWallet id 字段）自动生成的逻辑（不是通过构造函数经外部传入 ID，而是通过分布式 ID 生成算法来自动生成 ID）等等。VirtualWallet 类的业务逻辑会变得越来越复杂，也就很值得设计成充血模型了。
充血模式设计思考
充血模式中Service类的职责是什么？有必要所有层都涉及成充血么？
充血模式中Service类的职责
在基于充血模型的 DDD 开发模式中，将业务逻辑移动到 Domain 中，Service 类变得很薄，但在我们的代码设计与实现中，并没有完全将 Service 类去掉，这是为什么？或者说，Service 类在这种情况下担当的职责是什么？哪些功能逻辑会放到 Service 类中？
- Service 类负责与 Repository 交流。虚拟钱包实现中，VirtualWalletService 类负责与 Repository 层打交道，调用 Respository 类的方法，获取数据库中的数据，转化成领域模型 VirtualWallet，然后由领域模型 VirtualWallet 来完成业务逻辑，最后调用 Repository 类的方法，将数据存回数据库。之所以让 VirtualWalletService 类与 Repository 打交道，而不是让领域模型 VirtualWallet 与 Repository 打交道，那是因为我们想保持领域模型的独立性，不与任何其他层的代码（Repository 层的代码）或开发框架（比如 Spring、MyBatis）耦合在一起，将流程性的代码逻辑（比如从 DB 中取数据、映射数据）与领域模型的业务逻辑解耦，让领域模型更加可复用
- Service 类负责跨领域模型的业务聚合功能。VirtualWalletService 类中的 transfer() 转账函数会涉及两个钱包的操作，因此这部分业务逻辑无法放到 VirtualWallet 类中。
- Service 类负责一些非功能性及与三方系统交互的工作。比如幂等、事务、发邮件、发消息、记录日志、调用其他系统的 RPC 接口等，都可以放到 Service 类中
所以即使在充血模式中Service也是有必要的，只不过更薄，和业务实体隔离
Controller和Repo为何不充血设计
Controller 层主要负责接口的暴露，Repository 层主要负责与数据库打交道，这两层包含的业务逻辑并不多，前面我们也提到了，如果业务逻辑比较简单，就没必要做充血建模，即便设计成充血模型，类也非常单薄，看起来也很奇怪，实际上即使是面向过程的方式，只要做好控制，也可以：
- 对 Repository 的 Entity 来说，即便它被设计成贫血模型，违反面向对象编程的封装特性，有被任意代码修改数据的风险，但 Entity 的生命周期是有限的。一般来讲，我们把它传递到 Service 层之后，就会转化成 BO 或者 Domain 来继续后面的业务逻辑。Entity 的生命周期到此就结束了，所以也并不会被到处任意修改
- Controller 层的 VO。实际上 VO 是一种 DTO（Data Transfer Object，数据传输对象）。它主要是作为接口的数据传输承载体，将数据发送给其他系统。从功能上来讲，它理应不包含业务逻辑、只包含数据，而且VO的生命周期也有限，只在业务逻辑完成后被转为VO返回而已，也并不会被到处任意修改
所以综上所述，只有业务层被充血建模即可。
总结一下
DDD从代码上的区别很小，就是对Service层进行重新设计并将BO升级为Domain，但是从设计和思维模式上区别很大，它是一套自底向上的面向对象思维方式和开发流程，能让我们从业务建模的视角去看问题。同时要用辩证的看待贫血和充血，无论是哪种模式都是基于具体业务实现去实践，例如controller和repo就依旧可以保留贫血模式。
从可读性上来说：它可以把原来最重的service逻辑拆分并且转移一部分逻辑，可以使得代码可读性略微提高，另外，模型充血以后基于模型的业务抽象在不断的迭代之后会越来越明确，业务的细节会越来越精准，通过阅读模型的充血行为代码，能够极快的了解系统的业务，对于开发来说能说明显的提升开发效率。
从可维护性上来说：如果项目新进了开发人员，如果是贫血模型的service代码，无论代码如何清晰，注释如何完备，代码结构设计得如何优雅，都没有办法第一时间理解系统的核心业务逻辑，但是如果是充血模型，直接阅读充血模型的行为方法，起码能够很快理解70%左右的业务逻辑，因为充血模型是业务的精准抽象
![[Java]23种设计模式](https://ucc.alicdn.com/3mfxe2r26qbaq/developer-article1631534/20241030/75e0b318e301432d84f68edea4a889c7.png?x-oss-process=image/resize,h_160,m_lfit)
