Entities

Entities encapsulate enterprise-wide Critical Business Rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities can be used by many different apps in the enterprise.

If you don’t have an enterprise and are writing just a single application, then these entities are the business objects of the application. They encapsulate the most general and high-level rules. They are the least likely to change when something external changes. For example, you would not expect these objects to be affected by a change to page navigation or security. No operational change to any particular application should affect the entity layer.

— ©Robert C. Martin

Rule #2: Inter-aggregate references must use primary keys

Another rule is that aggregates reference each other by identity (for example, primary key) instead of object references. For example, as identity (for example, primary key) instead of object references.

This approach is quite different from traditional object modeling, which considers foreign keys in the domain model to be a design smell. It has a number of benefits. The use of identity rather than object references means that the aggregates are loosely coupled. It ensures that the aggregate boundaries between aggregates are well defined and avoids accidentally updating a different aggregate. Also, if an aggregate is part of another service, there isn’t a problem of object references that span services.identity rather than object references means that the aggregates are loosely coupled.

— ©Chris Richardson

NOTE: Clean Architecture entities and DDD domain entities differ significantly. Clean Architecture is more about ensuring the longevity and maintainability of software through strict layering and separation of concerns, while DDD is more focused on accurately capturing and implementing complex domain logic and fostering better communication between developers and domain experts.