4 ms·
So you create a class in the Domain which is responsible to save the domain object? And inside of this class you map the domain object to the persistency model?
by kenniskrag 5y ago
So you create a class in the Domain which is responsible to save the domain object? And inside of this class you map the domain object to the persistency model? Is that not a forbidden by the layer principle because now the domain model layer has a dependency to the persistency layer.
- DenisM 5y ago> So you create a class in the Domain which is responsible to save the domain object? Yes. > Is that not a forbidden by the layer principle because now the domain model layer has a dependency to the persistency layer. In my book it's fine. I find that in practice one-way dependencies are ok, so domain->persistence dependency is fine so long as there is no persistence->domain dependency. Simply avoiding loops will take you a very long way.
- kenniskrag 5y ago> In my book Which book? I see know that one can think of the domain model as most changed layer and if there is a bigger change it is because the domain model changes (e.g. business requirements). So a dependency from the domain model to other parts below are mostly fine.
- 5e92cb50239222b 5y ago> Which book? I believe it's used as an idiom. https://dictionary.cambridge.org/us/dictionary/english/in-my-book https://dictionary.cambridge.org/us/dictionary/english/in-my...
- marcosdumay 5y ago> Is that not a forbidden You will have a bad time with real software engineering if you take those rules as mandatory. Software engineering rules are like algebraic math postulates, they create common ground that let you explore and communicate some things. Not like legal rules that disallow you from doing something. Anyway, "layers" imply on single-way dependency. If you have completely independent code, two-way or multi-way dependency, it's something else.