Can crud logic be implemented in domain service for an aggregate root entity instead of this aggregate root repository in terms of DDD?

Question

Hi we are implementing a framework based on 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.

I mean Let'say we have two entities Order and OrderLine that are dependent eachother?

Order and OrderLine form aggregate together.Aggregate Root is Order(and also this is entity).Orderline is entity that depends on Order.

So There can be 2 approach in terms of DDD.

1)We can have only Order Repository based on the principle of per aggregateroot repository? and also we can have 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?

2)We can have seperate repositories for Order and OrderLine?(repository per entity)Also we can have a domain service that accepts OrderEntity.

IOrderRepository orderRepository = new OrderRepository();

IOrderLineRepository orderLineRepository = new OrderLineRepository();

We can use IOC container to inject repository dependencies.

OrderDomainService orderDomainService = new OrderDomainService(IOrderRepository orderRepository,IOrderLineRepository orderLineRepository);

orderDomainService.save(orderEntity);

Both Order and OrderLine are saved in the above save domain service method?

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.)

Shortly can crud logic of an aggregate like order entity(aggregateroot) be in a domain service?

Which method would you advise to me in terms of DDD best practices?

First or second? or another

Answer 1

Which method would you advise to me in terms of DDD best practices?

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).

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

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.