- DTO: The “domain model” for us. - DB objects: A poor flat view of those DTOs, for example complex subobjects can be jsonized, or mapped as a foreign key. Ba

- DTO: The “domain model” for us. - DB objects: A poor flat view of those DTOs, for example complex subobjects can be jsonized, or mapped as a foreign key. Basically it is the role of the DAO to transform the DTOs into DBOs and store them immediately, or read the tables and transform them into structured DTOs. Why? Because the DB representation is always ugly. So our application works mostly only with the DTOs. The trick is to make the DTOs rich: Adding methods onto them to ease manipulation, and add validation so that a DTO can only exist in a valid state (as much as possible, modulo when they come from the front-end). So it’s not “setDocument(abc)” then “setState(HAS_DOCUMENT)” then “setLastUpdated(now())”. It’s “.addDocument(doc)” and it changes the state accordingly, so the state is always coherent. So, our DTOs only have Json annotations on them. And merging DTOs and DB objects? Never succeeded even on a simple app. I wish we could write into tables without copying data into the DB objects.