An entity models a business concept through attributes and methods that manipulate those attributes consistently. An Invoice class, for example, represents what an invoice means to the system. Entities belong to the domain Model, alongside services that coordinate complex rules and repositories that retrieve or persist information. section 1.4
An entity should not automatically become the structure exposed to every client. Reusing the same object across repositories, services, and clients couples those layers: adding an entity field can break clients or expose information they should not see. section 4.2.3
Separate the entity from the client response
A repository retrieves an entity, a service uses it, and the result is sent to a client. Instead of serializing the entire entity, create a client-specific data structure and convert the entity before returning it. The entity can then evolve without forcing equivalent changes on clients. section 4.2.3
Use entities to:
- Represent recognizable business concepts such as invoices. section 1.4
- Keep attribute-manipulating behavior with the attributes it must maintain consistently. section 1.4
- Expose only the information a client needs through a separate data structure. section 4.2.3
Trace how sharing one entity across layers creates undesired coupling. section 4.2.3
