《设计模式之美》笔记：贫血和充血模型

• 基于贫血模型的开发模式：数据跟方法分离，最经典的就是Web项目常用的MVC结构。前后端分离后，后端的三层结构为 Controller层、Service层、Repository层，Controller层负责暴露接口给前端，Service层负责核心业务逻辑，Repository层负责数据读写。而每一层，又会定义相应的VO（View Object）、BO（Business Object）、Entity，它们只定义数据，不定义方法，所有操作这些数据的业务逻辑都定义在对应的Controller类、Service类、Repository类中。

• 基于充血模型的开发模式：数据和方法封装在同一个类中，如领域驱动设计（Domain Driven Design，简称DDD）。微服务加速了领域驱动设计的盛行。还是那MVC三层架构举例，基于充血模型的DDD开发模式中，Service层包含Service类和Domain类两部分，Domain类相当于贫血模型中的BO，不过，Domain和BO的区别在于Domain既包含数据也包含业务逻辑，而Service类变得非常轻薄。

• 总结：基于贫血模型的传统开发模式，重Service轻BO；基于充血模型的DDD开发模式，轻Service重Domain。从开发流程的角度，基于贫血模型的开发，开发快速，先定义数据，后根据需求的变化迭代业务逻辑，较少应用OOP概念和考虑代码复用；基于充血模型的开发，需要事先理清楚所有的业务，定义领域模型所包含的属性和方法。领域模型相当于可复用的业务中间层。新功能的开发，都基于之前定义好的这些领域模型来完成。所以，视业务复杂度而定，应该选择哪个模式来开发。个人认为，就是简单的功能，数据跟方法分开，聚焦在业务逻辑的快速迭代；复杂的模块，考虑清楚属性和方法，把数据和方法封装到一个类里，便于复用。

• DDD开发模式里，区别于Domain的职责，Service类主要有下面几个职责：
  • Service类负责跟Repository交流。Domain不直接跟Repository打交道，是为了保持领域模型的独立性，不与任何其他层的代码或开发框架耦合在一起，让其更加可复用（比如从一个项目拷贝到另一个项目里）。
  • Service类负责跨领域模型的业务聚合功能。
  • Service类负责一些非功能性及与三方系统交互的工作。比如幂等、事务、发邮件、发消息、记录日志、调用其他系统的RPC接口等。