# Keep DTOs, Models And Entities Separate

Stops one shape from serving the API contract, the domain and the database at once.

Follow these project instructions.
# Keep DTOs, Models And Entities Separate

Stops one shape from serving the API contract, the domain and the database at once.

Version: `1.0.0`

Three shapes, three jobs. A DTO is the contract with the caller. A model is what the service works in. An entity is what is stored. They may look alike early on, and they stop looking alike the moment either side changes.

Reusing one type for all three means the database schema is your public API. Renaming a column becomes a breaking change for clients; adding an internal flag leaks it to every consumer; and a field that should never leave the server travels out by default because nobody chose to send it - they only chose not to hide it.

Map explicitly at each boundary. The mapping code is the place where you decide what a caller sees, and its tedium is the point: it makes leaking a field an act rather than an oversight.

Entity types from a storage provider stay inside that provider's package. If one appears in an API contract, the contract now depends on where the data happens to live.

#### Constraints
- Do not expose a provider entity through an API contract.
- Never use one type as request DTO, domain model and stored entity at once.

#### Verification
- Each boundary has explicit mapping rather than passing the same object through
- No field reaches a client because nobody remembered to remove it
- Renaming a stored column does not change the API contract