CODEWITHSUNDEEP
domain-driven-design
Tyler Shao
Tyler Shao

Reputation: 156

Domain Driven Design - When to seperate one bounded context into two

While learning domain driven design, I learnt that we should keep two bounded contexts independent from each other. However I am having trouble decoupling two bounded contexts that really dependent on each other.

To be more specific, I am designing a Point Of Sales system. It has a Inventory management subsystem which manages the products in the inventory. It also has a Sales subsystem which is responsible for managing customer orders, transactions. They seem to be separated bounded context, however I can not decouple them:

  1. An order [in Sales context] has reference to a product [in inventory context].
  2. When user paying an order [which is done in Sales context], the product quantity should be decreased [which is done in inventory context].

I know I can use domain event and Saga to replace the cross boundary service calls, however just want to know am I designing this correct? Are Sales and Inventory really belong to two separated bounded contexts?

Upvotes: 1

Views: 873

Answers (1)

Alexander Langer
Alexander Langer

Reputation: 2893

If you instead separate these in three bounded contexts, you can make these dependencies cycle-free:

  • Product BC, where your products are managed (including price, weight, ...); no dependencies
  • Sales BC, where sales are handled; dependency on Product BC
  • Inventory BC, dependencies on Product and Sales BCs.

Usually sales are completely separated from inventory (i.e., you can make sales w/o having the product available yet). If you have a requirement that only products in stock can be sold, let your UI be responsible for offering only products for sale that are also in stock in your inventory.

Upvotes: 0

Related Questions