Domain-Driven Design – Integrating Aggregate Root with Open Host Service (OHS)

aggregatedomain-driven-designdomain-model

Here is the case: according to ubiquitous language – payment can be sent for processing to payment gateway (which is in different bounded context integrated via ACL (anti-corruption layer) + OHS/PL)

In local context, payment is aggregate root so I would expect design like this:

payment.send();

but the problem here is that payment needs to know how to send its state to other bounded context via ACL to OHS. So I need to inject this PaymentGatewayService/Adapter as argument:

payment.send(paymentGatewayService);

In this case paymentGatewayService returns some value object that can be processed with payment inside the send() method. But
I heard that this is not quite good practice to inject services to aggregate root via method arguments or DI, but maybe it's OK? The benefit here is that I'm not exposing aggregate structure to outside. Or should I create some domain service to cover it like:

Payment payment = ...
payment = paymentGatewayService.send(payment);
paymentRepository.store(payment);

In this case, I don't really like this inversion, because I must directly expose aggregate structure so gateway service can translate to its model.
Also this is causing anemia in payment aggregate.

How can I handle such situations properly??

Best Answer

But I heard that this is not quite good practice to inject services to aggregate root via method arguments or DI, but maybe it's OK?

There are trade offs.

Evans describes domain services as a construct to serve this role. So we pass to the aggregate an adapter that expresses the gateway concept in the domain language, so that the model can interact with it. The underlying implementation of the domain service probably delegates the actual work to an application service or an infrastructure service.

So, done correctly, it is completely consistent with the domain focused approach.

But it introduces some coupling between the side effect and the aggregate that you may not want

the failure modes of the side effect now pass through the aggregate
the aggregate and the side effect are coupled in time

Let's take a more careful look under the covers of your first example

payment.send(paymentGatewayService);

And try to break down explicitly what is going on

Payment::send(paymentGatewayService):
    x = this.getCurrentState()
    m = createPaymentMessage(x)
    y = paymentGatewayService.send(m)
    z = calculateNewState(x, y, m)
    this.setState(z)

Which is to say, that what we have here are three steps

we query the aggregate to discover the appropriate message to send, without touching the payment gateway
we dispatch the message to the payment gateway, without touching the aggregate
we update the aggregate using the response from the gateway as an input

and the trade off is: do we want those side effects in the aggregate, in the application, or possibly tucked into a different domain service that is responsible for the coordination?

PaymentProtocol::send(payment, paymentGateway):
    m = payment.createPaymentMessage()
    y = paymentGatewayService.send(m)
    payment.onPaymentSent(y)

In this design, the payment protocol orchestrates the side effects on the payment and the payment gateway. This gives you a clean aggregate (its responsibility is maintaining its own invariant), and keeps all of the process located in a single place.

In this case, I don't really like this inversion, because I must directly expose aggregate structure so gateway service can translate to its model. Also this is causing anemia in payment aggregate.

That's not quite right - the aggregate is still completely responsible for maintaining its own invariant; it's just absolved of the responsibility for managing a side effect that it is interested in. The aggregate is never exposing its own structure, it's only ever exposing a message that it created using its own structure.

It's still OK not to like it, of course.

Related Solutions

Design Patterns – Forcing Aggregate Root Child Access Through the Aggregate Root

I feel like you were really close, but just missed it

order = orderRepository.Get(123)
OrderService.AddOrderLine(order: order, product: "Chocolate Cake", amount: 3))
orderRepository.Save(order)

What you were looking for is more like this:

order = orderRepository.Get(123)
order.AddOrderLine(orderService: orderService, product: "Chocolate Cake", amount: 3))
orderRepository.Save(order)

Domain services support queries within the domain model - they don't write changes to the model; the aggregates change and protect the domain state. So as a rule, you want to pass the domain service to the aggregate, then let the aggregate pass current state to the service, as needed. For instance

// Order.AddOrderLine()
orderLine = orderService.createOrderLine(this.id, product, amount);
this.lines.add(orderLine);

Note the (implied) separation of responsibilities

The domain service creates an instance of the orderLine, using only the context provided to it. But there's no persistence here, it's just transient data in memory at this point.
The aggregate then evaluates the orderLine to determine whether or not it satisfies the invariant. If it does, the orderLine will become part of the graph of entities reachable via the aggregate root.

However, having a Save method on repositories that concern non-root aggregates, allows for saving changes made to them directly

That's not a good thing?

orderLine = orderLineRepository.Get(31923)
orderLine.Amount = 5
OrderLineRepository.Save(orderLine)

But if this orderLine is part of an order aggregate, then presumably the Order is expected to check that the state of the order is consistent. It can't do that if you insist on being able to mutate the subordinate entities directly.

Part of the point to aggregates is that all changes to the domain model must go through paths that force the model to remain consistent. Are all of the OrderLine methods going to walk back up the graph to the Order to ensure that the invariant is still satisfied?

Of course, this might actually be a hint that the aggregate boundaries are in the wrong place. If you should be able to modify OrderLine without the entire Order, then perhaps OrderLines are aggregate roots, and not merely subordinate entities. Your domain experts might tell you that discrepancies between the Order and OrderLines aren't actually particularly expensive; ensuring that they are rare (rather than eliminating them entirely) may suffice. Horses for courses.

Domain-Driven Design – How to Avoid Overlapping Aggregate Boundaries

A good starting point for you would be Yves Reynhout's Evolving a Model, where he describes the modeling of appointment scheduling for healthcare.

You might also want to review Greg Young's discussion of warehouse systems. The summary is this: if you have a reasonable way to detect and report a scheduling conflict in your data, you may not necessarily need to prevent violations from occurring.

One insight that helped me to grasp this is that the order that messages arrive is not a guarantee of correctness. Udi Dahan, in Race Conditions Don't Exist, observes

A microsecond difference in timing shouldn’t make a difference to core business behaviors.

Here's a message saying that Dr. Frankenstein should be in room A from 10:00 until 11:00; here's another message saying that she should be in room B from 10:30 until 11:30. It's clear that the two messages are not consistent, but we don't know which is right - in particular, there might already be a message coming that cancels the "wrong" appointment, we just haven't seen it yet.

In many cases, what we are really looking for is something like the solutions Greg Young describes in Stop Over Engineering; first escalate problems to the human beings, then work on identifying problems that are simple enough that solutions can be automated.

Systems that overly constrain to prevent conflicts often inflict disappointing experiences on the users. There was a data entry error, but before we can enter the correct data for this appointment, the system interrupts that tasks and insists that the error be corrected. Furthermore, correcting that error may be complicated.

If you keep in mind that the role of a scheduling system is to identify and resolve conflicts, rather than prevent them, you may find that you have a lot more freedom in how you design your aggregates.

Best Answer

Related Solutions

Design Patterns – Forcing Aggregate Root Child Access Through the Aggregate Root

Domain-Driven Design – How to Avoid Overlapping Aggregate Boundaries

Related Topic