Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Architecture Patterns: 5 minute read

orkhanscience.medium.com

Post reply on HN
Print view View original

31–40 of 73 posts

Re: Software Architecture Patterns: 5 minute read

#31

Post by laurent92 »

kenniskrag wrote: post #20

What I nerver understood: * How to disconnect the domain model from persistence. Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer. But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annot…

- 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.

Re: Software Architecture Patterns: 5 minute read

#32

Post by DenisM »

kenniskrag wrote: post #20

What I nerver understood: * How to disconnect the domain model from persistence. Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer. But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annot…

> 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.

Re: Software Architecture Patterns: 5 minute read

#34

Post by kenniskrag »

DenisM wrote: post #32
kenniskrag wrote: post #20

What I nerver understood: * How to disconnect the domain model from persistence. Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer. But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annot…

> 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…

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.

Re: Software Architecture Patterns: 5 minute read

#35

Post by DenisM »

kenniskrag wrote: post #34
DenisM wrote: post #32

Earlier quoted context omitted.

> 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…

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.

> 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.

Re: Software Architecture Patterns: 5 minute read

#36

Post by cyberbanjo »

devwastaken wrote: post #26
bewuethr wrote: post #10

Earlier quoted context omitted.

There's also the full-blown book version at https://www.oreilly.com/library/view/fundamentals-of-softwar...

$40 dollaryroos for that boy howdy. No wonder nobody knows how to make software, by the time you can afford a stack of these you already have the job.

The Architecture of Open Source Applications[1] book are available for free online, and that Fundamentals of Software Architecture is on LibGen.

1: https://aosabook.org/en/index.html

Re: Software Architecture Patterns: 5 minute read

#37

Post by 5e92cb50239222b »

kenniskrag wrote: post #28
Cthulhu_ wrote: post #27

Earlier quoted context omitted.

I'm building an application in this fashion at the moment in Go, and honestly, I think it's kinda painful. At some point I already merged the persistence with the domain model, so it's just the domain model with SQL related struct tags. I am tempted to merge it with the HTTP model as well, add JSON tags to it. But everyone is telling me it's a bad idea, so I'm really not sure. A more convenient way to copy properties…

> I am tempted to merge it with the HTTP model as well, add JSON tags to it. If you add a property which shouldn't be public you have to separate them. For example in the domain model you have a user with email but do not want to expose the email. Second argument: I usually create a simple struct for each method. For example I do not want, that they provide the id for post requests. I want to send the id on get reque…

> in the domain model you have a user with email but do not want to expose the email.

You can usually configure that out with @JsonIgnore or something like that. Although this works only for this particular (very simple) example and won't help with e.g. flattening multiple nested objects.

Re: Software Architecture Patterns: 5 minute read

#38

Post by kenniskrag »

DenisM wrote: post #35
kenniskrag wrote: post #34

Earlier quoted context omitted.

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.

> 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 tak…

> 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.

Re: Software Architecture Patterns: 5 minute read

#39

Post by 5e92cb50239222b »

kenniskrag wrote: post #38
DenisM wrote: post #35

Earlier quoted context omitted.

> 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 tak…

> 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.

> Which book?

I believe it's used as an idiom.

https://dictionary.cambridge.org/us/dictionary/english/in-my...

Re: Software Architecture Patterns: 5 minute read

#40

Post by marcosdumay »

kenniskrag wrote: post #34
DenisM wrote: post #32

Earlier quoted context omitted.

> 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…

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.

> 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.

Post reply on HN