CODEWITHSUNDEEP
architecturedomain-driven-designbounded-contexts
MarceliSzpak
MarceliSzpak

Reputation: 21

DDD - Validation reference id from other bounded context

I have a question regarding id validation from another bounded context. It is best to explain with an example. I have a billing context and a warehouse context. When issuing an invoice, I attach the product id to the item, then send an invoice event so that the context of the warehouse issues the warehouse document. The problem is that the billing context does not know if the product id on the invoice line belongs to an authorized user. I only assume asynchronous communication, so I cannot ask the context with the store if a given user has permissions to a given product.

I could send an event after issuing an invoice that an invoice was issued for a given product in the context of a given user and if there were any problems with the cultivation, I could raise an alarm. However, it does not seem very satisfying. For a year now I have not come up with any sensible solution to this problem. Thank you in advance for your help.

[EDIT] I would also like to point out that I am not interested in data duplication because I have a very large data volume and a very large number of types.

Upvotes: 2

Views: 426

Answers (2)

Julien Gavard
Julien Gavard

Reputation: 673

In addition to Levi Ramsey's complete answer, you can also see if the Saga pattern can solve your problem.

Upvotes: 0

Levi Ramsey
Levi Ramsey

Reputation: 20551

The options for data validation basically boil down to:

  • Invoice context asks the store context. While the interaction is synchronous (in that the invoice context's process of issuing an invoice is at least semantically blocked on getting a reply from the store), it's not incompatible with communicating over asynchronous channels (remember that HTTP very often presents a synchronous interface over an asynchronous channel): it largely requires the invoice context to be able to model an invoice's state as "issuing but not validated" as a waypoint between building and passing onto the warehouse.

  • An alternative to this is the invoice context being able to track on its own what products a user can order, with that being all that the invoice context needs to know about a user. Note that this implies some duplication of state with the store context, which you say you're not interested in (I'm including it for completeness).

  • It's possible from your limited description of the invoicing bounded context that it's so anemic it's really part of the store context (if it's performing more validations than the one you call out, this might not be true), in which case by putting invoicing in the store context you get the second option "for free".

  • Another option is to embrace eventual consistency and essentially have a service that watches published invoices and checks permissions. However, the permission validation functionality here is going to be performed via at least one of the foregoing approaches, so doing it this way is kind of begging the question.

In my experience high data volume (though it's not clear if you're talking about a stock (lots of data but might not change often) or a flow (lots of changes)) tends to be an argument for duplication via CQRS and friends, but you definitely know your situation better than I do, so we'll eliminate the second, and the fourth isn't very satisfying. So that leaves revisiting the domain model to see if invoicing is really part of the store (a consideration there is if it's possible to have an invoice covering multiple stores) and if that's not viable to model the validation in the invoicing context as something that's longer-running with a lot of interactions with other contexts.

Upvotes: 2

Related Questions