search

cosmicpython / book

A Book about Pythonic Application Architecture Patterns for Managing Complexity. Cosmos is the Opposite of Chaos you see. O'R. wouldn't actually let us call it "Cosmic Python" tho.
https://www.cosmicpython.com
Other
3.35k stars 529 forks source link

Ch 10 - How to handle Purchase Order without sync call #175

Open pedroabi opened 4 years ago

pedroabi commented 4 years ago

I would like to explore the use case of order purchase. Later in ch 10, you said that we should have ordering and allocation as bounded context and then we can use assync messaging to communicate across services. It seems ok to have a Ordering service and an Allocating service, but I will still need to make a sync call to guarantee that we are not going to place an order without stock. I suppose that I will need to coordinate from the Ordering service a sync call to Allocation service.

Can you make a little bit clear how to handle a Purchase Order use case without making a sync request to Allocation service?

hjwp commented 4 years ago

I don't have a good answer for this. at work, ordering and allocation are separate systems, and it occasionally happens that an order goes out of stock in between the time it's made and when it's allocate. we then offer the customer the option for a refund, or to wait for the rescheduled order date. but that's a business choice.

i can't speak to any experience about synchronous calls between services, but they would certainly be an option. the other option would be to rethink your context boundary -- if ordering and allocation need to be synchronous, maybe they should be part of the same bounded context...

hjwp commented 4 years ago

Maybe I can point to some further reading? Either the blue or the red DDD book have some more guidelines on where to draw bounded contexts, and Sam Newman's "Building Microservices" has some excellent discussion of sync vs async, and implementation patterns for distributed transactions...

xtaje commented 4 years ago

In addition to the options that Harry mentioned, you could introduce some notion of state to the Order ("Submitted", "Filled", "Shipped"). Order placement could run in a way that looks synchronous to the user, but is actually async.

Outside of that, things begin to get much more complex and involve things like workflow orchestrators and sagas. Bernd Ruecker's blog has a lot of good discussion on this, with examples in the retail shopping domain.