0

I have two bounded contexts, Store and Inventory. The Store context has the Product aggregate, the Inventory context also have an aggregate called Product. Product is a different concept inside each context.

Now in my Store context I want this behavior in the products: "Please select the items from stock needed to sell this product". So in this case the user will select multiple products in different quantities from the Inventory context, with that information the Store context can tell if the product has enough stock to be sold.

If I am right, my bounded context should be independent, I can't just select things from my Inventory context database from inside the Store context. So I think maybe using events, when a product is added to the Inventory context the Store context will be listening and will add this product to its context too, with another name.

Some questions:

Is this the right approach? Using events to sync data between bounded contexts?

When inside Store context how can I name the Product from the Inventory context? Is there any convention for that?

Thanks!

Improve this question
8
  • Have a look here
    – Robert Harvey
    Jun 8 at 18:53
  • Rather than going off reading online what are the various ways bounded contexts can communicate/interact, first let's see if you actually have two separate bounded contexts here. Just because you call them that. doesn't mean that that's what they are. Otherwise you're risking a lot of wasted time and effort learning about something that doesn't apply here, and you're risking introducing a bunch of unnecessary complexity. 1/2
    – Filip Milovanović
    Jun 9 at 0:17
  • 1
    So, when you say you have two BCs, what do you mean, specifically? What made you define them as such? In what sense are the two Product concepts different? In what way having a unified model (a single BC) makes the system more complex and harder to understand and work with? Because that's the problem bounded contexts are there to solve; if they make things more convoluted, then something went wrong. 2/2
    – Filip Milovanović
    Jun 9 at 0:17
  • If you want the communication to happen in-memory rather than through the wire, you can solve this with domain services. Or application services. The way to avoid Store to be coupled (aware) of Inventory BC and details, is declaring an interface within Store BC that outer layers must implement and inject following IoC. Whether the implementation of that interface gets the data from a remote service, Queue or from the DB is irrelevant for Store BC
    – Laiv
    Jun 9 at 7:59
  • @FilipMilovanović Thanks for your reply. I think Store and Inventory are two BC because they will be very complex and each one will focus in one thing. There's another BC I haven't mentioned, the Manufactory BC. This one will receive orders to manufacture a product, and here Product will have just a name and a bill of materials.
    – Cleyton Carvalho
    Jun 9 at 11:25

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.