Transitioning a monolith into microservices: Analyzing the data attributes

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:

  1. Cataloging - name, description
  2. Pricing - price (this one will shock you)
  3. 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.


Like this message? I send out a short email each day to help software development leaders build organizations the deliver value. Join us!


Get the book!

Ready to learn how to build an autonomous, event-sourced microservices-based system? Practical Microservices is the hands-on guidance you've been looking for.

Roll up your sleeves and get ready to build Video Tutorials, the next-gen web-based learning platform. You'll build it as a collection of loosely-coupled autonomous services, developing a message store interface along the way.

When you're done, you'll be ready to contribute to microservices-based projects.

In ebook or in print.