本文转载自【如何解耦】：https://codedecoupled.com/ane...领域模型领域模型是解决复杂业务逻辑的建模工具/思想。大神MartinFowler将其定义为包含行为和数据的对象模型。使用领域模型时，我们的目标是构建丰富的领域模型，但由于某种原因，广泛使用了一种已弃用的模式（贫血模型）。贫血领域模型贫血领域模型是一种众所周知的反模式，但摆脱这种想法并不容易。因为这种设计开发起来很快，也很容易理解。不经意间，它可以出现在我们的代码中。例如，我们的应用程序中有一个活动用户函数：classUserextendsOrmModel{publicsetStatus($status){$this->status=$status;}publicgetStatus(){return$this->status;}}classUserService{publicactivate(User$user){if($user->getStatus()==='blacklisted'){thrownew\Exception('Userisblacklisted');}$user->setStatus('active');$用户->保存();}}乍一看，这个模型还不错：数据库表通过映射构建了一些ORM类，各个类型之间有一定的关系，服务层（Servicelayer）进行分层管理。但是让我们考虑一下。User类无非是一些getter和setter，符合包含数据的领域模型的标准，但缺少最重要的部分：行为。将业务逻辑放到服务类（Serviceclass）中，形成类似于事务处理脚本的面向过程的编程方式，与领域模型所提倡的面向对象编程背道而驰。一个健康的服务层应该是很薄的，它的主要职责是调用充实的领域模型来完成业务流程。这种贫血模型建立在领域模型的成本之上，而没有带来领域模型的好处。拥塞领域模型拥塞领域模型是领域模型提倡的建模方法。顾名思义，多域模型是包含行为和数据的对象模型。例如上面的激活用户函数：}$this->status='active';}}classUserService{publicfunctionactivate(User$user){$user->activate();$用户->保存();}}完善的拥塞域模型可以降低Bug风险，帮助我们更直观地构建业务模型。构建充血域模型需要开发人员具有良好的面向对象思维。能够准确划分服务层逻辑和领域层（DomainLayer）逻辑。经验法则是，在构建服务层时，业务逻辑应该密封到领域层，业务逻辑封装应该密封到服务层，所以服务层应该很薄。这里的薄不能完全代表代码量，而是指业务逻辑的内容。规定正确的领域模型的目的是简化复杂的问题，而不是使简单的问题复杂化。正如MartinFowler所说，领域模型并不是包治百病的灵丹妙药。开发人员在解决问题时需要对症下药：如果你处理的问题可以通过增删改查来完成，那么使用ActiveRecord这样的数据驱动模型是最好的解决方案。是一个更合适的解决方案。使用领域模型来解决简单的CURD问题会成为一个slasher，得不偿失。本文转载自【WhyDecoupled】：https://codedecoupled.com/ane...，如果你也对TDD、DDD和简洁代码感兴趣，欢迎关注公众号【WhyDecoupled】，以及一起探索软件开发之路。
