控制粒度的域服务

时间:2013-05-23 17:11:58

标签: domain-driven-design domainservices

我认为域名服务应该只代表域概念,但似乎我们也应该使用它们来控制域层接口的粒度(这也会阻止域知识泄漏到应用层)并将客户端与实体值对象分离:

Eric Evan的DDD书,pg。 108:

  

虽然这种模式讨论强调了表达性   将概念建模为服务,该模式也是有价值的   控制域接口中粒度的方法   层,以及将客户端与实体和值分离   对象。

     

中等粒度,无状态服务可以更容易重用   系统,因为它们封装了重要的功能   简单的界面。细粒度的域对象可以贡献   知识从域泄漏到应用层,其中   域对象的行为是协调的。

a)如果我们还引入了不代表域概念的域名服务,而只是控制粒度,请不要引入非域名概念进入域名?如果是这样,那不会伤害域名模型吗?

b)与上层的大部分通信是否应通过中等粒度的域对象完成?因此,对于通过细粒度域对象进行通信的每个用例,我们应该引入中等粒度域服务?< / p> c)Eric Evan的DDD书,pg。 108:

  

编码约定可以清楚地表明这些对象是公正的   SERVICE接口的交付机制,而不是有意义的域   对象。

他指的是哪些编码惯例?

更新

我认为你说这句话是在描述应用服务不是 域名服务

我知道 Application Services 及其目的,但我认为作者正在描述域名服务,因为他警告知识泄露细粒度域对象,可能会发生应用层

  

...以及将客户端与实体和值对象分离。   中等粒度的无状态服务可以更容易重用   系统,因为它们封装了重要的功能   简单的界面。 细粒度域对象可以为此做出贡献   知识泄漏从域进入 应用层,其中   域对象的行为是协调的。

如果我们想阻止知识泄漏域层进入应用层,那么就不应该(至少我的逻辑)在域层中构建“障碍”(即中等粒度服务)?

第二次更新:

A)

  

关于粒度,域服务提供类似的角色   应用程序服务。

您在谈论什么样的域名服务??创建一个只是为了控制粒度或......?

b)中

  IMO,这是一个优先考虑的应用服务   存在于单独的应用程序层项目中或与其他项目一起存在   域对象。

即使应用程序服务存在于域层中,您也正在调用服务(其目的仅是控制粒度)?

c)中

  

应用程序服务可以很好地防止知识泄漏   从某种意义上说,这是它的核心工作。

但是由于应用层中存在“ barrier ”(即中等粒度服务),这不是域知识确实泄漏到应用层(但是没有进一步感谢应用服务)?

d) 我们可以说应用层域层客户端,作者在本书中警告说没有域知识必须泄漏到客户端。为什么应用层(即应用服务)是此规则的例外?

由于

1 个答案:

答案 0 :(得分:2)

  

a)如果我们还引入了不代表域名的域名服务   概念,但只是控制粒度,我们不介绍   非域名概念进入域名?如果是这样,那不会伤害域名模型吗?

虽然服务不会在域中引入任何新行为,但它们也不会引入非域概念。我特别将这些服务application services视为为域提供封装角色 - facade。服务上的每个方法都代表一个域用例,它直接委托给域对象。这使得域层的客户端更容易,因为他们不需要担心协调存储库并在聚合上调用合适的行为方法。相反,他们在应用程序服务上调用一个方法。

  

b)与上层的大多数沟通应该通过完成   中等粒度的域对象?因此,对于每个用例来说   通过我们应该的细粒度域对象进行通信   介绍中等粒度的域名服务?

外层应该调用应用程序服务,而应用程序服务又委托给聚合或域服务。请注意,应用程序服务与域服务不同。应用程序服务可以完全封装域,使得其接口不会公开域对象,而是依赖DTO在外层和应用程序服务之间传递消息。除了保护域之外,这还提供了利用域模型之外的其他东西来实现用例的机会,例如transaction script

  

他指的是哪些编码惯例?

一种约定可以是服务名称中存在Application,例如 CargoApplicationService 。另一个惯例是将应用程序服务(BTW也可以作为命令处理程序实现)放入项目中的 Application 模块中。

修改

以现代C#风格查看实现本书中讨论的域的this project on GitHub

<强>更新

关于粒度,域服务与应用程序服务起着类似的作用。 IMO,优先考虑应用程序服务是存在于单独的应用程序层项目中还是与其他域对象一起存在。在应用程序服务和域对象之间创建额外的障碍可能会成为一种不必要的抽象。应用程序服务可以很好地防止知识泄漏,从某种意义上说,这是它的核心工作。

更新2

a)我一般都在谈论域服务,因为它们都倾向于增加实体和VO之外的粒度。

b)是的,因为它仍然捕获域概念,即比用于实现它们的域对象更不精细的用例。当然,应用程序服务的关注点很大程度上与域正交,但并不总是有理由将它们放入不同的层。

c)是的,但是你无法在一起泄漏领域知识。如果您有一个名为Customers的数据库表,该表对应于Customer实体,则您将域知识泄露到数据库中。重点不在于防止所有泄漏,而是在内聚区域周围创建边界,这样在进行更改时,它们可以被隔离到特定层。

d)应用程序服务在域对象周围创建一个外观,有效地建立一个障碍,以便除了app服务之外的域的客户端具有可以使用的干净界面。通过这种方式,app服务是一个“例外”,因为它位于域对象和外层之间。