Invoke persistence and services from aggregate root or from domain services?

Question

I am new to Domain Driven Design, and I am struggling with where to invoke calls to persistence, locking and/or internal and external services. In the aggregate root? In a surrounding application or domain service? Or somewhere else? And why?

As an example, let's consider a shopping cart. It should support:

1. Adding a shipping address. When doing so, a shipping address must be provided and validated against a public online address validation service. The actual http call can be placed in an adapter. But where is the adapter invoked?

• From the shopping cart aggregate root. Pro: The business logic within the aggregate root can handle various validation outcomes differently (like requesting to user for missing information). Con: It may take several seconds, and is it ok for an aggregate root to invoke such an external service?
• By the ValueObject that contains the address. Pro: the ValueObject is already validated when received by the aggregate root. Con: The ValueObject must invoke an external http service, which seems quite heacy for just a value object.
• From a surrounding applicatrion/domain service?
• Somewhere else?

2. Adding products to the cart. While adding a product, it should be checked in an inventory service that the product is on stock. The inventory service is an application/domainservice in the same application. Is it ok that the aggregate root invokes the inventory service as part of its "addProduct" method? Or should this be done first by a surrounding domain service?
3. Persisting state. When products are added, or while checking out, it is important that internal state is persisted. Persistence can be provided by means of an adapter that wraps around a database or some other kind of storage. But where is the act of persisting (and loading of data) triggered?

• From the shopping cart aggregate root? Should an aggregate root be responsible for invoking the injected persistence adapter? Pro: The aggregate root has control on which part of the data when to persist (like the entire state, or just one newly added product). Con: aggregated root gets multiple responsibilities (business logic + persistence).
• From a surrounding application or domain service? Pro: Keeps the aggregate root clean. Con: More complicated to communicate from the aggregate root which exact data needs to be persisted.

4. Synchronization/locking: Some operations require multiple actions. Like adding a product is checking the inventory service, adding it to an internal list, updating the total order amount, and then persisting. It is not okay when two parallel invocations of add-product make the internal administration or storage corrupt which can happen when no locking is applied. So, where should the locking be performed?

• From the shopping cart aggregate root itself? Pro: It is in control of when to lock, when to use a read lock, when to use a write lock. Con: It is yet another responsibility. Shouldn't an aggregate root focus on domain logic instead of technicalities like locking?
• From a surrounding application/domain service? Pro: Aggregate root is kept clean. Con: All code that invokes the aggregate root must go through the application/domain service, and the application/domain service must have knowledge on how the aggregate root works in order to determine which kind of lock (read/write) is required.

In our company, we are all very new to DDD, and we have a lot of different opinions. We have experience with (virtual) actor frameworks like Darlean where actors are similar to aggregate roots and are fully self-contained, so they provide their own locking, invoke persistence when they need, invoke other services, et cetera. On the other end, we use an approach where our aggregate roots are as minimal as possible, contain very little business logic, and do not invoke external or domain services at all. All of that is performed in an application service around the aggregate roots.

What is your opinion/expertise/advise? Where to put external service invocations / domain service invocations / persistence invocations / locking invocation? In the aggregate root? In a surrounding application or domain service? Or somewhere else? And why?

Answer 1

Peristing state.

Evans discusses this in the original book: transaction control belongs outside of the domain model (see the discussion of REPOSITORY in Chapter 6).

Adding a shipping address Adding products to the cart

In the ideal case, your domain model's responsibilities are limited to the manipulation of local representations of domain information. Retrieving and distributing domain information is generally regarded as an application concern, rather than a domain concern.

One benefit to this approach: your domain code doesn't get cluttered with a bunch of logic designed to compensate for the fact that you are running in a distributed environment. In your specific instance, we're trying to isolate your shopping card logic from the realities that HTTP calls can fail.

In the general case, it can be unsatisfactory to have the application code fetch all of the data (because fetching information is expensive and not always necessary, or because we don't know what information to fetch until the domain logic runs). The common solution here is to pass the capability to fetch the information as an argument, usually in the form of a "domain service". This doesn't eliminate the need to compensations, but may allow you to use implicit handling of those conditions (aka "exceptions"), avoiding pollution of your domain code.

An alternative approach calls for developing a sort of protocol between your application code and your domain code, so that the domain code can ask for what it needs, and the application code can fulfill that need or handle the failures.

Synchronization/locking

As best I can tell, this is still something you want to manage outside of the domain model (why should our shopping code need to know or care how many copies of it are running, or what other processes manipulate the same information?)

There's not, that I can think of, a lot of literature on this point. Probably the best place to start is Pat Helland 2005. As best I can tell, the real consensus is "try very hard not to have this problem".

Answer 2

Agregate root Technical details such as external service calls or persistent calls should not be available here. The agregate root should ensure the focus of business logic and manage the core business processes.

My suggestion is to organize the technical details in a surrounding application or domain service, while keeping the core business logic at the total root. This ensures the code remains clean and there is a clear separation of responsibilities