AnemicDomainModel - 需要更简单的解释

Question

我今天阅读了这篇文章，并试图澄清一些事情。本文是否意味着模型对象应该包含业务逻辑？ 例如，假设有一个 Student 对象，我们通过 Hibernate 从数据库中检索该对象。本文是否说 Student 对象还应该包含业务逻辑，而不是只有 getter 和 setter？

Answer 1

不管日期如何，马丁·福勒所说的内容在今天和八年前一样重要。 Fowler 并没有声明您应该将持久性混合到域对象中，恰恰相反：

“还值得强调的是，将行为放入域对象中不应与使用分层将域逻辑与持久性和表示等事物分开的可靠方法相矛盾的责任。”

您应该再次阅读这篇文章，因为该文章很好地描述了这种反模式，但我将尝试根据您所要求的内容为您总结它：

如果您要创建域模型，是的，您的域对象应该包含业务逻辑和状态，并且应该通过传达业务含义的方法来更改域实体的状态。贫乏领域模型是一种反模式，因为您会付出额外一层类的成本，但并没有获得好处。当域层传达的意图与使用活动记录样式方法（数据集等）完全相同的意图时，为什么还要费心去映射数据库的域层呢？因此，本文并没有说您应该有一个“学生对象”，但它指出，如果您这样做，您应该明确地向该类添加状态。

由于当今可用的技术，文章中关于如果您不对域进行建模，则没有一组对象来表示您的模型的观点可能会有点令人困惑。有一些很棒的工具可以毫不费力地在一组 POCO 和数据库之间移动数据（Nhibernate、EF、Simple Data、Massive、Dapper 等），所以在回顾中我会说你最终可能会得到一组当今大多数解决方案中的“实体”，真正的区别在于这只是数据库模型还是真正的领域模型。

最后，我将向您展示域入口点（命令处理程序）和域模型之间交互的示例。下面显示的方法位于命令处理程序中，该处理程序使用请求来更改域中的某些内容。请注意，域代码之上的层只是获取域实体并调用域上的一个方法？这是很重要的一点，因为我们正在建模的工作流程完全封装在域中，而不是域代码之上的层或其他任何地方：

    public void Handle(AddEmailAddressForAlerts command)
    {
        var agent = _repository.GetAgent(command.AgentKey.AgentId);
        agent.AddEmailAddressForAlerts(new EmailAddress(command.EmailAddress));
    }

Answer 2

注意日期——该引文已经有八年多了。

马丁·福勒显然是一个非常聪明的人，我喜欢这篇文章的观点，但对此持保留态度。一般来说，将状态和行为封装在一起是一件好事，但它应该与分层考虑因素相平衡。持久性与业务逻辑不同。我仍然有一个单独的持久层；我不会将持久性放入模型对象中。

教条应该受到各种形式的挑战。了解别人的想法，但要独立思考。