domain-driven-designrepository-patternddd-repositoriesrepository-design

DDD. Should I modify a entity inside a repository?

I have a question about implementing DDD and repository pattern. Should I modify a entity inside a repository?

Let's say I have an Order and want to mark that order as finished. As I see this I have two choices.

    1. 
var order _orderRepository.GetById(1);
order.Finish();
_orderRepository.Update(order);

...where the change is persisted to the database in the Update call.

2.

var order _orderRepository.GetById(1);
var finishedOrder = _orderRepository.Finish(order);

...where the change is persisted to the database in the Finish call.

Is there a advantage of using one method over the other? What is the DDD-way of doing this?

Solution

  • You should not modify it in the repository.

    The reason is that the repository is responsible of abstracting away the persistence (i.e. reading/writing to the data storage).

    If you also make it responsible of some business logic you are violating the Single Responsibility Principle.

    If you are doing automated testing, it also means that you have to do integration tests to be sure that the database communication/mapping works and then unit tests to verify the business logic that you introduced in it.

    It can seem trivial. But it's only trivial the first time you violate the principle. But one violation usually leads to another and another and finally an application that isn't as easy to maintain :)

    An application where classes have mixed responsibilities are also harder to navigate. Each time you want to update a feature you have to go through all layers to find where the actual logic is done.