Saying goodbye to the Monolith - The one Entity abstraction

 In most systems I encounter there is a strong focus on "Entities". We try to model everything in this "Entity" abstraction where one "Entity" is typically mapped to one table.

Every piece of data that is related to this "Entity" is encapsulated in this object. This could sound fine from a OO perspective but can bring us on a path where we get too much coupling and information from multiple domains get encapsulated in the same object.

A first step in the right direction is to focus on the difference between related entities and child entities. Could some parts of the data move to a child entity or even a value object?

A second step is to identity your bounded contexts and start to split your entity across the boundaries of these contexts. This means you will typically not end up with one entity but many entities each containing a subset of the data.

Let's take a look at an example...

Imagine that we have a Product entity.

	public class Product
	{
	public int ProductID {get;set;}
	public string Name {get;set;}
	public string Description {get;set;}
	public Money Price {get;set;}
	public Size Size {get;set;}
	public int ItemsInStock {get;set;}
	}

view raw ProductEntity.cs hosted with ❤ by GitHub

If we try to split this across the context boundaries, we could end up with something like this:

	namespace Catalog
	{
	public class Product
	{
	public int ProductID {get;set;}
	public string Name {get;set;}
	public string Description {get;set;}
	}
	}
	namespace Purchasing
	{
	public class Product
	{
	public int ProductID {get;set;}
	public Money Price {get;set;}
	}
	}
	namespace Shipping
	{
	public class Product
	{
	public int ProductID {get;set;}
	public Size Size {get;set;}
	public int ItemsInStock {get;set;}
	}
	}

view raw ProductSplit.cs hosted with ❤ by GitHub

This not only allows us to encapsulate the logic a lot better, it gives use a more evolvable system where changes in one context don't impact another.