language-agnostic - 如何避免贫血领域模型并保持关注点分离？

Question

似乎决定让您的对象充分认识到它们在系统中的角色，同时仍然避免域模型对数据库和服务层有太多依赖？

例如:假设我有一个具有修订历史记录的实体，以及数据引用的几个“查找表”，您的实体对象应该具有从某些查找表中获取详细信息的方法，无论是通过提供访问查找表行，或者通过将方法委托(delegate)给它们，但要做到这一点，它取决于数据库层从这些行中读取数据。另外，当实体被保存时，它不仅需要知道如何保存自身，还需要知道如何将条目保存到修订历史记录中。是否有必要将几十个不同的数据层对象和服务对象的引用传递给模型对象？这似乎使逻辑变得比仅仅将瘦模型来回传递到服务层对象更复杂，但我听过许多“智者”推荐这种结构。

Answer 1

非常非常好的问题。我花了很多时间思考这些话题。

通过注意到富有表现力的领域模型和关注点分离之间的紧张关系，您展示了深刻的洞察力。这很像我问的问题Tell Don't Ask and Single Responsibility Principle中的张力。 .

这是我对这个主题的看法。

领域模型是贫乏的，因为它不包含领域逻辑。其他对象使用贫血域对象获取和设置数据。您所描述的内容对我来说听起来不像领域逻辑。可能是，但一般来说，查找表和其他技术语言很可能是对我们有意义的术语，但对客户不一定有任何意义。如果这是不正确的，请澄清。

无论如何，域对象的构造和持久化不应该包含在域对象本身中，因为那不是域逻辑。

因此，要回答这个问题，不，您不应该注入(inject)一大堆非域对象/概念，例如查找表和其他基础设施详细信息。这是一种担忧泄露到另一种担忧中。领域驱动设计中的工厂和存储库模式最适合将这些问题与领域模型本身分开。

但请注意，如果你没有任何领域逻辑，那么你最终会得到贫乏的领域对象，即一袋袋无脑的 getter 和 setter，这就是 some shops claim to do SOA / service layers 的方式。 。

那么如何才能两全其美呢？如何让域对象仅关注域逻辑，同时保持 UI、构造、持久性等不受影响？我建议您使用类似 Double Dispatch 的技术，或某种形式的restricted method access .

这是双重调度的示例。假设您有这行代码:

entity.saveIn(repository);

在您的问题中，saveIn() 将具有有关数据层的各种知识。使用 Double Dispatch，saveIn() 可以执行以下操作:

repository.saveEntity(this.foo, this.bar, this.baz);

存储库的 saveEntity() 方法拥有如何在数据层中保存的所有知识，这是它应该做的。

除了此设置之外，您还可以:

repository.save(entity);

它只是调用

entity.saveIn(this);

我重新阅读了这篇文章，发现该实体仍然很薄，因为它只是将其持久性分派(dispatch)到存储库。但在这种情况下，实体应该很薄，因为您没有描述任何其他域逻辑。在这种情况下，您可以说“去他的 Double Dispatch，给我访问器。”

是的，你可以，但在我看来，它暴露了太多实体的实现方式，而这些访问器会分散域逻辑的注意力。我认为唯一应该具有获取和设置的类是名称以“Accessor”结尾的类。

我很快就会把这件事结束。就我个人而言，我不会使用 saveIn() 方法编写实体，因为我认为即使只有 saveIn() 方法也会使域对象分散注意力。我使用友元类模式、包私有(private)访问，或者可能使用 Builder pattern .

好的，我完成了。正如我所说，我对这个话题非常着迷。