When Does an Entity Stop Being a Data Model?

Title: Determining When an Entity Ceases to Be a Standalone Component

The evolution of backend applications often begins with a few simple tables, endpoints, and an ORM or repository layer. However, as the application grows, entities can become increasingly complex. Instead of residing in one place, the semantics of an entity like a "Customer" may now involve various system concerns such as authorization, validation, lifecycle management, concurrency control, and event handling.

This phenomenon is sometimes referred to as "entity gravity," where more and more system concerns orbit around a single entity.

At some point, the architecture must adapt to accommodate these distributed entity concerns. The problem arises when changing one entity-level rule requires coordinating many unrelated parts of the application. For instance, adding optimistic concurrency necessitates coordinating authorization, validation, lifecycle checks, and database updates.

To address this issue, one approach is to introduce an explicit architectural boundary around the entity itself. This boundary separates the entity's infrastructure from the application's business logic. By doing so, the application retains ownership of business decisions, while the entity infrastructure handles common mechanics and guarantees related to entities.

One practical example of this approach is modifying how updates to an entity are handled. Instead of manually coordinating all the required steps within the application controller, the application can depend on a higher-level contract provided by the entity infrastructure. This contract handles tasks such as actor authentication, input validation, lifecycle checks, version verification, and the creation of outbox events for the updated entity.

By adopting this explicit entity boundary, the application can avoid duplicating coordination logic across multiple entities. Instead, it can rely on a higher-level service that abstracts away the complexities associated with entity updates. The entity infrastructure then becomes responsible for providing the necessary hooks, such as authorization, validation, lifecycle management, and concurrency mechanisms, without dictating the specific business logic.

It's important to note that the entity boundary should not turn into a new place to handle all domain questions. Business semantics, such as determining when an entity is "qualified," should remain outside the scope of the entity infrastructure. The boundary should focus on providing infrastructure support for the entity, rather than absorbing the entire domain model.

While this approach can help mitigate the challenges posed by entity complexity, it is not a silver bullet. Persistence, for example, remains a critical aspect of an entity's management. An ORM (Object-Relational Mapping) can efficiently handle persistence and object-relational mapping tasks, but it should not be the sole focus of the entity infrastructure.

In conclusion, as backend applications grow in complexity, it becomes increasingly important to identify when an entity should no longer be considered a standalone component. The emergence of entity gravity, where system concerns orbit around a single entity, signals the need for an explicit architectural boundary around the entity itself.

By introducing this boundary, applications can decouple business logic from infrastructure concerns, allowing for better separation of responsibilities, easier maintenance, and a more scalable architecture.