CODEWITHSUNDEEP
oopdomain-driven-design
lascarayf
lascarayf

Reputation: 3733

In DDD, where should validations involving more than one context be done?

Suppose we have the Customer and Order contexts in a monolithic application. When creating the Order I need to verify that the customerId exists, otherwise the system could remain in an inconsistent state.

Would I have to call the Customer application service from the Order service? eg. customerAS.exist(customerId)

Could I call the Customer repository directly from the Order application service ?

Upvotes: 1

Views: 72

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57249

Suppose we have the Customer and Order contexts in a monolithic application. When creating the Order I need to verify that the customerId exists, otherwise the system could remain in an inconsistent state.

What's the business impact of being inconsistent in this way: One dollar? Ten dollars? One hundred billion dollars?

If the business impact of the error is inconsequential, then don't compromise your design and performance to mitigate it.

If the impact would be catastrophic, then you are probably going to need to design your system so that it locks all of the information that must be consistent with making a change. (You probably don't have this problem, because a microsecond difference in timing shouldn't make a difference to the business.) That will normally mean abandoning the idea that customers and orders are separable systems; perhaps they merge, or parts of the two get moved to a new third system that can manage these information relationships.

In between, we can consider "best effort" mitigations, like consulting an unlocked copy of the information, and hoping the answer found there is fresh. For instance, we could ask the Customer system for a copy of the answer, but we need to be aware of the fact that the real answer could change while the answer is in flight.

In a microservices design, you probably wouldn't want to use a synchronous call to another system that might be down for maintenance or upgrade, but instead to use a locally cached copy of the answer, which is intermittently refreshed using some asynchronous mechanism.

Horses for courses.

Upvotes: 1

rascio
rascio

Reputation: 9279

Could I call the Customer repository directly from the Order application service ?

The DDD police will not arrest you if you do it 😅
...but it would be better to don't do it.

The fact is that in that way you are coupling the implementation of the Order domain with the implementation of the Customer domain, and in case later on you want to change the customer domain to don't use repositories, or you want to separate them into two different deployables you will have to refactor this integration point and use something else instead of the repository directly.

Using an interface that explicit the contract and the queries/commands of a domain (the service) helps in decoupling what you need to do with how you do it, and you will be more free to change the how you do certain stuff reimplementing the same contract the service was already exposing

Upvotes: 1

Related Questions