This is part of a long-running series on breaking up a monolith into microservices.
Suppose you have an e-commerce site, and it had a
products table. Maybe that table has columns like:
id name description price quantity
What’s the problem here?
Well, which of these attributes requires transactional consistency with each other? Udi Dahan gives a useful rule of thumb: can you articulate a requirement between them that requires that transactional consistency? For example, to know the name, do you need to know the price?
If you apply this rule, you can piece out three different domains:
- Cataloging - name, description
- Pricing - price (this one will shock you)
- Quantity - inventory
All these attributes share a common identifier, but that doesn’t mean that they’re the same business process, and when we’re looking to find domain boundaries, we’re looking for processes.
Well, we can pull these into separate tables, and as a first pass, you could take your endpoint that edits these and have it write to these separate tables in a single transaction. We’ll look at code to do that tomorrow.