1)在大多数情况下,每个都Aggregate Root
应该定义自己的事务边界,在这种情况下,我们不需要IUnitOfWork
在Domain Layer
.
a)我假设在这种情况下,一个好的选择是让repository
(用于aggregate
强制invariants
在其中应用)包含它自己的实例UoW
(如果使用 EF,那么这个UoW
实例可能只是类型DbContext
)?
2)
a)但是如果出于某种原因transaction
跨越多个aggregates
(因此一次aggregate
需要更改多个),那么是否也不Domain Layer
需要包含IUnitOfWork
接口?
IUnitOfWork
b) 暴露接口不会Domain Layer
违反持久性无知规则吗?
c) 如果b)是,那么暴露IUnitOfWork
的目的不就失败了repositories
吗?
回复阿列克谢·拉加:
1)
I would advice against exposing repositories to aggregates. Repositories are there to give you aggregates, that's it.
a)虽然我认为大多数 ddd 架构师在将 repos 暴露给聚合时没有问题(我只是问,因为我阅读了几篇关于 repos 和 DDD 的文章,我得到的印象是作者不反对暴露 repos聚合 - 但现在我不再那么确定了)?
b)所以您也反对将存储库暴露给域服务?
c)从你的回答来看,我猜你认为暴露IUnitOfWork
是违反 PI 的?
2)Note that although my command handler (app service in a way)...
您通常将命令处理程序实现为应用服务吗?
3)
public void Handle(ApproveOrderCommand command)
{
var order = Repository.Get(command.OrderId);
property.Approve(command.Comment, ServiceRequiredForOrderApproval);
Repository.Save(order);
}
是property.Approve(...)
一个错字,你的意思是order.Approve(...)
?
提前感谢