0

因此，在我的第一家公司工作了 10 年之后，我开始了我的第二份开发人员工作，并没有真正感觉到自己获得了高级开发人员的头衔。这是 Java 开发，但我们正在使用一个贫乏的领域模型，在我看来，该应用程序是一个巨大的难以测试的混乱。不幸的是，我现在使用的代码库完全相同，最近我接受了另一次采访，采访者将他们的 Hibernate 模型描述为轻量级并且只包含 setter getter。因此，这似乎在整个行业中很普遍。

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

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

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

  • 您如何限制每个服务中对其他服务的依赖？即 OrderCancelService 需要 CustomerAccountService 和 PaymentService 以及 RefundCalculatorService 和 RewardsAdjustmentService 等 这往往会导致测试中出现多个模拟对象，从而使测试过于依赖于实现

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

  • 你对服务对象应用告诉，不问原则吗？我看到很多服务返回值，然后调用服务使用这些值在执行流程中做出决策。

4

1 回答 1

1

你可以考虑你的持久性模型，你现在认为它是贫血的域模型，因为它是 - 你的域模型状态的持久性模型。

如果你这样做，你可能可以创建一个真正的领域模型，它的状态将存储在持久性模型对象中（状态模式）。然后，您可以在这个新的域模型中包含您的逻辑。阅读您上面的评论，我想说您可以将您的“管理器/服务”类转换为状态机，如果它们与事务边界匹配，您可以将它们称为聚合，并让它们在 POJO 中的状态由 Hibernate 保持，就像现在一样。

于 2017-05-17T17:37:27.880 回答