DDD,封装和分层架构：我的域名是否过于贫血？

Should the service layer contain so much logic? if not where should it
go?

我假设你在这里谈论Application层中的服务,而不是Domain层.看起来你的域名对象几乎是贫血的,有些人认为这是一种反模式,但对此有很多争论.

从务实的角度来看,它是否包含在新应用程序中利用域所需的所有业务规则和行为？如果没有,则可能意味着当前在应用程序端的某些部分需要移动到域层.

请注意,我在这里谈的是纯粹的域业务规则,而不是特定于应用程序的规则.例如,某些操作必须通过具有4个步骤的向导执行,在最后一步结束时要求用户进行确认,并且在最后一步之后将所有修改刷新到持久性存储中特定的业务规则,而不是域规则.因此,不应将它们移动到Domain层.

if the domain,should aggregate roots hold references to repositories?

IMO一个聚合根不应该拥有对它自己的存储库的引用,并且知道如何存储它自己,因为它打破了持久性的无知,并在域对象中引入了一个额外的责任,这将使它混乱.但是,聚合根可能偶尔会持有对另一个实体的存储库的引用.

How should transactionality be handled?

我会说有两种类型的交易：

>“应用程序”层中的“用户”事务,也称为“工作单元”.这些是跨越用例的高级事务,或者是Web应用程序中网页生命周期的最后一个事务(“在视图中打开会话”). ORM框架通常提供管理这些事务的工具.
>域层中的事务.它们可以由域对象或服务启动.例如：FundsTransferService.Transfer()可以在内部使用事务.在这里,您可以使用平台的基本事务处理.

Should entities (or aggregate roots) hold references to domain
services? If so,how should they obtain the references?

是的,实体有时可以调用域服务.域服务包含不属于任何实体的域规则和行为.您可以对这些依赖项进行硬编码或将它们注入实体中,具体取决于所需的分离级别.

In order to get a new id for an entity,we must call a stored
procedure,which we have wrapped in a repository. Where would you
reference this? Some complex methods on Entities which need to create
many child entities would need to reference this?

我不建议为按需访问的实体生成ID生成.正如大卫指出的那样,当你新建实体时,在语言层面生成一个Guid通常是个更好的主意.

如果您仍想要ID生成路由,则调用ID生成器通常是您的实体的Factory而不是实体本身的作业.