小编Tim*_*imC的帖子

我目前正在使用.net和nhibernate为旅游行业的客户开发一些相当大的应用程序,并且我遇到了一些实施DDD的问题,以及团队内部就最佳方式进行分歧的问题.我希望有人可以提供一些指导.

目前,我们已经在域外实现了一个服务层,每个聚合根([EntityName]服务)都有一个服务.所有其他层使用这些服务通过GetByThis()和GetByTheOther()等方法获取对聚合根的引用.我们从其他层调用域名都是通过这些服务进行的.

这些服务包含对存储库的注入引用(这些引用在其他地方都没有引用),并且还负责所有保存/更新行为和管理事务性.服务方法的复杂性越来越高,有时候行为似乎属于域,就像条件创建逻辑一样(如果property = this set child对象,则为其他东西).我们的域实体主要有简单的方法,如GetByThis()和HasAThing().我觉得我们正在失去域名的表现力.

我的主要问题是:

• 服务层是否应包含如此多的逻辑？如果不是它应该去哪里？如果域,应该聚合根持有对存储库的引用？如果是的话,如何注入这些(进入创建聚合根的工厂？)
• 如何处理交易？
• 实体(或聚合根)是否应保留对域服务的引用？如果是这样,他们应该如何获得参考？
• 为了获得实体的新id,我们必须调用存储过程,我们将其存储在存储库中.你会在哪里参考这个？需要创建许多子实体的实体上的一些复杂方法需要引用它吗？

编辑

感谢@ david-masters和@ guillaume31精心设计的答案.

你帮助我解决了我感觉到的"臭味代码".

首先,我应该说我们有一个(非常)传统的oracle DB来应对,因此Id生成要求(以及其他问题).

对于任何看过这个问题的人来说,这两个答案都提出了很好的建议,但对我来说,这是最好的建议:

"从务实的角度来看,我会问自己:如果我想参与我的Domain层的一部分并在另一个应用程序中重用它,它是否包含我在新应用程序中利用域所需的所有业务规则和行为？如果没有,那么可能意味着当前在应用程序端的一些部分需要移动到域层."

考虑到这一点,我重新评估了我们的域和服务层,现在我相信我已经解决了我们的设计问题