Implementing Bounded Context in Domain Driven Design

Question

I recently decided to learn Domain Driven Design. I came up with a hypothetical application and tried designing the architecture for it. It is a simple Poing-Of-Sale application with bounded contexts Sales and Inventory. This is where I have two conflicting designs when implementing the code for these bounded contexts.

Design #1:

• Anything and everything that has to do with inventory belongs in inventory bounded context.

• If a sales order comes in, the request initially enters the sales bounded context, then one of the steps to make the sale, you must check the inventory to see if the item is available. In which case, you request the inventory context (however this is done within the system). Inventory context will check the database and respond back with availability confirmation. This way any other bounded contexts that need any kind of inventory involved logic would use this bounded context to achieve it. Code is encapsulated and good to go.

Design #2:

• The division of bounded contexts are strictly at the business level divisions in their operational contexts.

• If a sales order comes in and hits the sales bounded context, it should contain all the logic in code that has to do with sales. It would check the database whether an inventory is available via the service, it would then remove that item from the inventory, record the sales in database via the service again, send out an sales made notification email to admin if this is a requirement. Just everything and anything that has to do with sales will all happen in this bounded context. Once the sale is made, it could fire an event sale made, and inventory context would listen to this to check the inventory in the database, see if new purchases need to be made to bring in new inventory or not as it is an operation related to inventories at the business level.

I am just trying to understand what Domain Driven Design approach is in such system. Thanks.

=================================

After some thought this is the added question to the original.

Let's say your business needs to do shipping. Whether it would be due to making a sale (Sales Bounded Context) or due to a warranty replacement (Support Bounded Context). What if shipping itself is complicated depending on situations. Where certain products or shipping addresses you need to make the decision to ship it yourself or via some 3rd party shipping company using a web service. Does the "shipping" deserve its own Shipping Bounded Context? Or it simply is just another domain logic embedded in the Sales Bounded Context and the Support Bounded Context? This is all within the case of simple retail store domain.

Answer 1

Design #1 is the correct one. Inventory context should be the only one which decides and knows how to check for inventory. It could be the inventory context is checking from multiple places and those could be changing based on meta data updates as new data warehouses come online. At some point retailer might decide to have all physical shops as data warehouses as well.

Similarly shipping should be a context as well. Notes above said we should not aim for distributed system but I don't see why not if that provides agility.

Answer 2

My 2 cents... Design #2 seems better as Design #1 should lead you to a distributed system. You do not want a distributed system. You should not take storage or tables into account before getting the business. Just consider business, and when you get it, consider how you could be able to get your BC run in complete isolation (offline mode vs distributed mode). If data is missing, then consider using Domain Events to propagate this knowledge to your BC.