领域驱动设计 – “丰富的领域模式”是否违反单一责任原则？

An interesting thread刚刚打了这个问题时就出现了.我不认为这回答了我的问题.

我已经在.NET MVC3中工作了很多,在那里它是希望有一个贫血模型.查看模型和编辑模型最好是愚蠢的数据容器,您可以从控制器传递到视图.任何一种应用程序流都应该来自控制器,并且视图处理UI的问题.在MVC中,我们不想在模型中有任何行为.

但是我们也不希望控制器中有任何业务逻辑.对于更大的应用程序,最好保持域代码与模型,视图和控制器分离,并且独立于模型,视图和控制器(通常为HTTP).因此,有一个单独的项目,在任何其他之前提供域模型(实体和价值对象,根据DDD组成聚合).

我已经尝试从一个贫穷的模式中转移到一个更丰富的领域代码,我在想放弃.在我看来,像包含数据和行为的实体类违反了SRP.

以Web为例,一个非常常见的情况,撰写电子邮件.给定一些事件,给定一个EmailTemplate,EmailAddress和自定义值组成一个EmailMessage对象是域的责任.该模板作为具有属性的实体存在,并且自定义值作为用户的输入提供.我们还要说明的是,EmailMessage的FROM地址可以由外部服务(IConfigurationManager.DefaultFromMailAddress)提供.鉴于这些要求,似乎一个丰富的域名模型可以使EmailTemplate负责撰写EmailMessage：

public class EmailTemplate
{
    public EmailMessage ComposeMessageTo(EmailAddress to,IDictionary<string,string> customValues,IConfigurationManager config)
    {
        var emailMessage = new EmailMessage(); // internal constructor
                                            // extension method
        emailMessage.Body = this.BodyFormat.ApplyCustomValues(customValues);
        emailMessage.From = this.From ?? config.DefaultFromMailAddress;
        // bla bla bla
        return emailMessage;
    }
}

这是我在富域模式的尝试之一.添加此方法之后,EmailTemplate的责任在于包含实体数据属性和撰写邮件.大概15行长,似乎把课堂从真正意义上成为一个EmailTemplate分散了,而IMO,它只是存储数据(主题格式,正文格式,附件和可选的/回复地址) ).

我最终把这个方法重构成一个专门的课程,唯一的责任是组合一个EmailMessage给出以前的论据,而且我更开心了.事实上,我开始喜欢贫血的领域,因为它有助于我分开责任,使课堂和单元测试更短,更简洁,更集中.似乎使实体和其他数据对象“没有行为”可以很好地分离责任.还是我跟踪这里？

有利于富域模型而不是贫血模型的论据取决于OOP的价值主张之一,它将行为和数据保持在彼此之间.核心优点是有助于推理代码的封装和内聚.丰富的域模型也可以被视为 information expert模式的一个实例.然而,所有这些模式的价值在很大程度上是主观的.如果更有用的是保持数据和行为分开,那么就这样,虽然你也可以考虑其他人看代码.我更喜欢尽可能地封装.在这种情况下,更丰富的域模型的另一个好处是将某些属性设置为私有的可能性.如果一个属性只被一个方法用于该类,为什么要将其公开？

富域型是否违反SRP取决于您对责任的定义.根据SRP,责任是改变的一个原因,它本身就需要一个定义.这个定义一般取决于手头的用例.您可以声明模板类的责任是模板,其中包含所有的含义,其中之一是从模板生成消息.其中一个模板属性的更改可能会影响ComposeMessageTo方法,这表示这可能是一个单一的责任.此外,ComposeMessageTo方法是模板中最有趣的部分.模板的客户端不关心如何实现该方法或模板类中存在什么属性.他们只想生成基于模板的消息.这也赞成保持数据旁边的方法.

领域驱动设计 – “丰富的领域模式”是否违反单一责任原则？

相关文章