Entity Obsession

I coined a term a few years back without realising I had coined it. So this is me cashing it in. Entity Obsession. Its the ugly grown up brother of Primitive Obsession coined by Kent Beck back in the 90’s, and is the route cause why many of our systems go through waves of simplicity, to complexity and crippling refactor.

Most systems in the wild are designed around the Entity – a person, a car, an organisation. It holds the state or data of this real world abstract. It’s a model designed to fix, solve or perform logical operations around a real world concept. In the example below we have a car entity – we can service it and MOT it; it has properties available to help us perform the logical operations (or commands) and view the state of the car at any moment.

Overtime, the entity grows as more properties (fields) are added to it to solve other problems required by the business. This only increases with time.

The Car entity now contains properties that allow it to display the state of, make decisions and execute all commands encapsulated in Servicing, Road Tax, Mileage, Registration etc. This leads to increased complexity and cognitive load – engineers need to understand how the properties are used, by what system. Without this domain knowledge, a change to an apparently innocuous property (perhaps named poorly) can cause a failure (usually into production) in the service over there.

This is because the entity creates implicit dependencies between all services. These dependencies are hard to understand and reason with (by AI agents and humans!). This will lead to change causing defects in unpredictable ways in the system. More validation, more checks, more logic is added to attempt to protect against these defects… only further compounding complexity by orders of magnitude.

Over time, our software becomes more complicated and harder to change – until the cost of change exceeds the value of the change. This is when organisations usually wake up to being in real trouble and a green field refactor is performed at great cost – or the company goes bust!

This is the long term consequence of entity obsessed architecture that uses the entity to store state, render current views and execute commands across service boundaries.

Leave a Comment

Your email address will not be published. Required fields are marked *