Full round replay — entities at the boundary

Pass: The API contract becomes the schema. Adding a column publishes it, renaming one breaks every client, and both happen in migrations that nobody reviews as API changes. The performance problems are real and secondary.

Fail: Leads with lazy loading and stops there.

Pass: Yes — a password hash, an internal note, a soft-delete flag, added months after the endpoint was written. No code changed, so no review would catch it; the change under review was a database migration.

Fail: Calls it theoretical.

Pass: The serialiser touches them. With open-in-view on, one query per association after the transaction commits — where no timer is watching. With it off, LazyInitializationException mid-response, so the client gets a 200 and a truncated body.

Fail: Only knows one of the two.

Pass: Each side references the other, so a serialiser walking the graph never terminates — StackOverflowError, or a huge response first. The mapping is correct; walking it without knowing where to stop is not.

Fail: Blames the mapping.

Pass: It works and puts a serialisation concern on a persistence class so one consumer can read it. The next consumer that needs that field cannot get it. A reasonable stopgap, not the design.

Fail: Offers it as the answer.

Pass: It is more code, and the code is the point — the response becomes something a person wrote and a reviewer can see. For read endpoints a projection or constructor query is usually less code than the entity version, because it removes the mapping too.

Fail: Restates the principle without engaging.

Pass: Worse. Mass assignment — a caller sets any field the entity has. Sending an id turns a create into an update against an arbitrary row, and sending a role escalates. The request DTO is the allowlist.

Fail: Treats it as symmetric with the response case, or fine.

Pass: The mapping is happening after the transaction — the service returned the entity and the controller mapped it. The DTO only helps if it is built while the session is open. A transaction should end with a fully-formed value object.

Fail: Assumes the DTO itself was wrong.

Pass: Three records. One class cannot satisfy three contracts without annotations that contradict each other, and separate records mean a change for one consumer cannot break the others — which is what pays for the duplication.

Fail: Proposes one class with conditional serialisation.