4 ms·

> Not much gained imho. The more complex your system gets the more you will appreciate this division. However at the outset it just makes things more complex t

by DenisM 5y ago

> Not much gained imho. The more complex your system gets the more you will appreciate this division. However at the outset it just makes things more complex than the situation warrants and it's not clear if the system will ever grow large and complex enough to pay for this expense. I recommend creating your domain model as a simple wrapper around the persistence model. This way if the whole system never gets complex you will retain 95% of simplicity and if it does get complex you're one refactoring away from making your "shallow" domain model into a full-blown domain model. Likewise the outbound part of your view/DTO model can be a simple wrapper around the domain model. Inbound models will probably have to be their own classes with extra mapping. The latter might be a bit of a pain (in ASP.NET MVC, for example), however I suspect the pain is instructive - making your inbound DTO a copy of the entire object could be simply the wrong path altogether.

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...
      - DenisM 5y ago
        indeed
      - myohmy 5y ago
        You are technically correct, the best kind of correct.
- 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.

by DenisM 5y ago

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...
    - DenisM 5y ago
      indeed
    - myohmy 5y ago
      You are technically correct, the best kind of correct.
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.