[英]Can crud logic be implemented in domain service for an aggregate root entity instead of this aggregate root repository in terms of DDD?
Hi we are implementing a framework based on DDD?嗨,我们正在实现一个基于 DDD 的框架? But as per my search and as per majority's idea,in terms of best practices Aggregate root crud logic should be in aggregate repository and also repositories should be per aggregate root instead of per entity.
但是根据我的搜索和大多数人的想法,就最佳实践而言,聚合根 crud 逻辑应该在聚合存储库中,并且存储库应该是每个聚合根而不是每个实体。
I mean Let'say we have two entities Order and OrderLine that are dependent eachother?我的意思是假设我们有两个相互依赖的实体 Order 和 OrderLine?
Order and OrderLine form aggregate together.Aggregate Root is Order(and also this is entity).Orderline is entity that depends on Order. Order 和 OrderLine 形式聚合在一起。Aggregate Root 是 Order(这也是实体)。Orderline 是依赖于 Order 的实体。
So There can be 2 approach in terms of DDD.因此,就 DDD 而言,可以有两种方法。
1)We can have only Order Repository based on the principle of per aggregateroot repository? 1)基于per aggregateroot repository的原则,我们只能有Order Repository吗? and also we can have genericCrudRepository.
我们也可以拥有 genericCrudRepository。
OrderRepository orderRepo = new OrderRepository();
orderRepo.save(orderEntity);
In this above save method of aggregateroot repository,the implementation can be like the below在上述聚合根存储库的保存方法中,实现可以如下所示
genericCrudRepository.save(orderEntity);
genericCrudRepository.save(orderEntity.OrderLines);
Both Order and OrderLine are saved in the above save repo method? Order和OrderLine都保存在上面的save repo方法中?
2)We can have seperate repositories for Order and OrderLine?(repository per entity)Also we can have a domain service that accepts OrderEntity. 2)我们可以为 Order 和 OrderLine 提供单独的存储库吗?(每个实体的存储库)我们还可以拥有一个接受 OrderEntity 的域服务。
IOrderRepository orderRepository = new OrderRepository();
IOrderLineRepository orderLineRepository = new OrderLineRepository();
We can use IOC container to inject repository dependencies.我们可以使用 IOC 容器来注入存储库依赖项。
OrderDomainService orderDomainService = new OrderDomainService(IOrderRepository orderRepository,IOrderLineRepository orderLineRepository);
orderDomainService.save(orderEntity);
Both Order and OrderLine are saved in the above save domain service method? Order 和 OrderLine 都保存在上面的保存域服务方法中?
inner implementation of save method of domain service may be like the below.域服务的保存方法的内部实现可能如下所示。
orderRepository.save(orderEntity);
orderLineRepository.save(orderEntity.OrderLines);
In terms of domain service,actually domain service is the extension of domain entities that is not in one particular aggregate.If the code scope exceed one entity(here is blurry.Is this entity or aggregate root? as per my understanding if it exceeds aggregateroot,we should make domain service to implement logic.)在域服务方面,实际上域服务是域实体的扩展,不在一个特定的聚合中。如果代码 scope 超过一个实体(这里是模糊的。这个实体还是聚合根?根据我的理解如果它超过聚合根,我们应该做域服务来实现逻辑。)
Shortly can crud logic of an aggregate like order entity(aggregateroot) be in a domain service?很快,像订单实体(aggregateroot)这样的聚合的 crud 逻辑可以在域服务中吗?
Which method would you advise to me in terms of DDD best practices?就 DDD 最佳实践而言,您会向我建议哪种方法?
First or second?第一还是第二? or another
或其他
Which method would you advise to me in terms of DDD best practices?
就 DDD 最佳实践而言,您会向我建议哪种方法?
DDD tends to be fairly quiet about how the plumbing works (bespoke domain models have a lot of value; but the plumbing isn't normally where your competitive advantage lies). DDD 往往对管道的工作方式相当沉默(定制的域模型有很多价值;但管道通常不是您的竞争优势所在)。
Your domain entities aren't going to care (they don't normally interface with the repository at all.您的域实体不会关心(它们通常根本不与存储库交互。
My concern would be with the failure modes:我担心的是故障模式:
orderRepository.save(orderEntity);
// HOW DO YOU RECOVER FROM A CRASH BETWEEN THESE TWO LINES?
orderLineRepository.save(orderEntity.OrderLines);
There are possible answers (ex: both repositories participate in the same Unit of Work), but they aren't obvious from looking at this code.有可能的答案(例如:两个存储库都参与同一个工作单元),但从查看此代码来看,它们并不明显。
In particular, there's may be a requirement that the orderlines and the orders are stored in the same place (so that the transaction that manages the changes can control both together).特别是,可能需要将订单行和订单存储在同一位置(以便管理更改的事务可以同时控制两者)。 And so we ask - should we be able to see the storage constraints in the code?
所以我们问 - 我们应该能够看到代码中的存储限制吗?
From what I've seen, "best practice" is to write code that looks like the aggregate is stored together, because managing failures cost effectively requires that we store the aggregate together -- you can think of aligning the design with the persistence constraints as a way of reducing technical debt从我所见,“最佳实践”是编写看起来像聚合存储在一起的代码,因为有效地管理故障需要我们将聚合存储在一起——你可以认为将设计与持久性约束对齐为一种减少技术债务的方法
if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down -- Ward Cunningham, 2009
如果我们未能使我们的计划与我们当时理解的思考财务对象的正确方式保持一致,那么我们将不断因这种分歧而绊倒,这会使我们放慢脚步——Ward Cunningham,2009
Substitute "persistence" for "financial objects".用“持久性”代替“金融对象”。
Design is what we do to get more of what we want than we would get by just doing it.
设计是我们所做的,以获得比我们仅仅做的更多的我们想要的东西。 -- Ruth Malan
——露丝·马兰
Choosing the appropriate "what we want" for your circumstance is an important part of the design process.为您的情况选择合适的“我们想要的”是设计过程的重要组成部分。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.