How to resolve Order and Warehouse bounded contexts dependency?

Question

I am working on DDD project and I am currently focused on two bouned contexts, Orders and Warehouse.

What confuses me is the following situation: Order keep track of all the placed orders, and warehouse keeps track about all the available inventory. If user places one order for certain product item, that would mean one less item of that product in a warehouse. I am oversimplifying this process, so please bear with me.

Since two domain models are placed inside of a different BC, i am currently relying on eventual consistency ie. after one item has been sold, it would eventually be removed from the warehouse.

That situation unfortunately leads to the problem scenario where another user could simultaneously make another order of the same item, and it would appear as available until eventual consistency kicks is. That is something it is unacceptable by the domain expert.

So IMO I am stuck with two options

• merge order and warehouse (at least the part regarding product inventory, units available in warehouse) into one BC
• have Order BC (or microservice if you wish) to be dependent of Warehouse BC (microservice) in order to pull a live product units available

Which option does actually follows DDD patern? Is there another way out?

Answer 1

You could use a reservation system with a timeout.

Using a messaging analogy: With a broker-style queuing mechanism (such as RabbitMQ) you get a message from the queue and you have control over it until you either acknowledge that it can be removed from the queue or you release it back to the queue.

You could do the same thing in your ordering process. You reserve any items on your order. SO when you add them they have a status of, say, reserving and upon sending some message to reserve the items. If the response comes back you can decide how to proceed. Perhaps you could add any items that cannot be reserved onto a back order or try again later.

There are going to be different ways to approach this. Depending on your business case it may be acceptable to only check availability when someone really accepts the order.

If you domain expert reckons it is totally unacceptable that having this resolved at the end of the process then you could move it to the start. The issue is of course that user A could reserve and never buy thereby losing user B as a customer; whereas only applying the real "taking" of the item at the end of the process is closer to ensuring a purchase. But that is a business decision.

Answer 2

This issue is a really great example of where reality actually is eventually consistent. Is it really the best thing to decline an order if there is no inventory currently in the warehouse - even if there was a replenishment due in the next 20 minutes?

What if the item was actually on the shelf, but the operator hadn't yet keyed it into the system?

Sometimes designers and domain experts assume that people want 100% consistency, when really, users might be willing to accept a delay in confirmation of their order, if it increased the chance that their order would be accepted rather than rejected.

In the case above, why make it the user's job to retry their order N minutes later? In an eventually consistent system, you can accommodate such timing flexibility by including a timeout to retry the attempt to fulfill the order for a period of time before confirming to the client that it really wasn't possible.

There are technical solutions that will give you 100% consistency, but I think really this is not a technical challenge but a cultural/mindset one, changing people's minds about what is possible & acceptable to achieve an what is actually a better outcome.

Answer 3

IMO you can build a PlaceOrderSaga which will ask for inventory availability before placing the order.