如何在没有其他选择的情况下充分利用贫血领域模型

Question

所以我在第一家公司工作了10年之后开始了我的第二个开发人员工作，而不是真的觉得我获得了高级开发人员的称号。这是java开发，但我们正在使用贫血域模型，在我看来，应用程序是一个巨大的难以测试的混乱。不幸的是，我现在正在使用的代码库是完全一样的，我最近接受了另一次访谈，其中访谈者将他们的Hibernate模型描述为重量轻，并且只包含了setter getters。因此，这似乎在整个行业中非常普遍。

有很多文章将贫血领域模型描述为反模式，还有一些文章描述了它对于简单系统来说非常好。但是，我还没有看到任何能够充分利用ADM的大型企业系统的例子。

有没有人有这方面的经验？是否存在创建松散耦合系统的最佳实践，该系统包含可读且实际有价值的单元测试？我真的很想为自己的工作感到自豪但却失去了希望。

编辑： 对于倡导业务逻辑包含在服务中的开发人员：

• 如何限制每项服务中其他服务的依赖关系？即OrderCancelService需要CustomerAccountService和PaymentService以及RefundCalculatorService和RewardsAdjustmentService等。这往往导致测试中的几个模拟对象使测试过于依赖于实现

• 如何限制每个服务方法中的参数数量？由于一切都需要传递，对象不能对自己的数据进行操作，这似乎会导致非常庞大且令人困惑的方法签名

• 您是否申请告知，不要求原则来服务对象？我看到很多服务返回值，然后调用服务使用这些值来执行流程中的决策。

Answer 1

您可以将您现在认为是贫血域模型的持久性模型视为您的域模型状态的持久性模型。

如果这样做，您可能可以创建一个真实的域模型，其状态存储在持久性模型对象（状态模式）中。然后，您可以在这个新的域模型中使用您的逻辑。阅读上面的评论，我会说你可以转换你的经理/服务＆＃34;对于状态机的类，如果它们与事务边界匹配，则可以将它们称为聚合，并且现在通过Hibernate将它们的状态保存在POJO中。