Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
One of the most common pitfalls I think I’ve fallen into is focusing too much on data entities rather than service capabilities. What tends to happen is building up a domain model of behaviors related to single entities.
As I’ve mentioned in my post about using language to find service boundaries, you can have the same entity that lives in a different context, but that owns specific behaviors and data.
This blog post is in a series. To catch up check out these other posts:
Entities
I’m not entirely sure where the focus on entities comes from. I suspect it the rise of ORMs has something to do with it as well as the general relational database table design.
In the world of monolithic applications and databases, it’s common to see a singular table that represents an entity. A massive Product table with 100 columns isn’t unusual.
What is unusual when living in a monolith is to think of that Product table being split up into multiple Product tables across multiple databases. This is a big mental leap.
Service Capabilities
But the reality is your application doesn’t often require all of the data related to an entity. Likely it needs very little of it. An exercise to see what it actually needs is by looking at the business logic related to a particular capability.
In our distribution example I’ve been using through this series, if I were to look at the Inventory Adjustment functionality in the Warehouse Service, do you think it requires the Product Selling Price?
An inventor adjustment is used to reconcile the deviation from what physically is in the warehouse for a product and what our system says. Why would there be a deviation from the system, well physical products sitting in a warehouse can be broke or be stolen. The real point of truth is the physical warehouse, not a number in a database.
As you might have guessed, an Inventory Adjustment doesn’t need the selling price.
What this illustrates is we don’t need to have a singular Product entity backed by a singular product table. We can separate these entities into multiple Product entities that live in various services.
What they will share is a common identifier, in our case a SKU to identify the product.
Once you start focusing on the behaviors and capabilities you can identify the data they encapsulate you can start splitting them into multiple entities across the services that own those behaviors.
Blog Series
More on all of these topics will be covered in greater length in other posts. If you have any questions or comments, please reach out to me in the comments section or on Twitter.