Duplicating classes in both data model (jpa layer) and domain model is not a problem. Actually they should be separate most of the time. Start design by generating domain model objects like entities, values objects, aggregate without ever thinking about data layer and related libraries like jpa, EF. Sometimes you do not even create a database table (data model) that corresponds to a entity or a part of aggregate, they might be retrieved from an external rest service.
6 жыл бұрын
Lots of wisdom here.
@Boss-gr4jw5 жыл бұрын
SQL in presentation objects. This is just so wrong. Also the suggestion to use same objects for database mapping and domain logic. These should always be separate. There is no justification for having framework dependencies in domain model. Even for demo purpose, you could show it for simplicity, but never say that it is fine to practice it on real project. This leads to mess and make refactoring a pain.
@ebichu81264 жыл бұрын
If we have coupled persistence and domain layers, it would be a pain in the ass. Entity Mapping structure and domain structure can be soooo different depending on the domain logic.
@gombike953 жыл бұрын
@@ebichu8126 This is a DDD talk, which means that in the presented theoretical project we start building up the system with Object Oriented Design and then much more later we can also start thinking about the detail how to store the state of our domain objects. At prototyping phase you might not even want to make a db connection, just to use an in-cache repository. However, if you are working on a legacy system, most of the time you have no choice but using a so called anti corruption layer and to hydrate your domain objects through that (this was also mentioned by Edson Yanaga). On the other hand, decorating your domain objects with JPA annotations might seem to be weird for the first time, but it can save you a lots of time in the end. It has only a few disadvantages like the protected empty constructor... but in the end you don't need to write the mapping functions between domain objects and jpa entities, which could be introduced later anyways with ease if the team decides so for whatever reason.