12 ms·

DDD, Hexagonal, Onion, Clean, CQRS, How I put it all together (2017)

93 points by sdeframond 4y ago

jmclnx 4y ago
When I saw DDD, I was thinking the debugger, which is rather nice, but seems not to have been updated for well over 10 years https://en.wikipedia.org/wiki/Data_Display_Debugger https://en.wikipedia.org/wiki/Data_Display_Debugger
barbarbar 4y ago
When adding small features you end up jumping all over the place in all "layers". So a little change in controllers, services, repositories, entities. So I am not sure? This post mentions package by feature/component. But still seem to have this strict layered approach.
bayesian_horse 4y ago
I hate CQRS with a passion. Why would you do this to yourself voluntarily?
- kmac_ 4y ago
  Because there's no mixing of applying changes to the state of the system and retrieving the state. Testing becomes much easier and looks like a business DSL on the system (also connects well with functional core, imperative shell). Also for the heavy read systems you can easily introduce performance improvements as the read path is separated. Out of curiosity, what issues did you have with CQRS? How was it handled? I would like to know because maybe it was applied in an inconvenient way. Some developers that worked with classical layered architecture for years have a problem with CQRS, DDD and FCIS, but when it clicks it's "Oh wow, it makes a lot of things simpler" moment for them. There are also drawbacks of course and that approach fits well to bussines solutions, so you can't find many applications in OSS, which are mostly technical solutions.
  - bayesian_horse 4y ago
    Oh I just prefer functional programming. Perfect testability. Also Django, while arguably not really FP is still perfectly testable, and not dealing with any of all of that. Why would I want to manage at minimum three classes for every endpoint? Maybe this has some justification in a situation with a couple hundred devolpers on software handling millions of dollars worth of stuff... but otherwise??
twawaaay 4y ago
Don't put it together. Learn all this stuff, understand it deeply. Then use it when you find it improves whatever you are working on. If you start putting it all together you will most likely only confuse other developers, especially juniors. Don't do it. The point of gathering all this knowledge should be making the application simpler and easier to maintain. So introduce stuff gradually and only when you find the added complexity pays out.
- thdespou 4y ago
  This is probably a syndrome of overhyped lead developers trying to "engineer" a solution without consulting with the team beforehand. They read a bunch of articles, decide that it's the "best" solution and blend everything together in a soup of tools that don't make sense. I've seen that happening many times with bad results every time.
  - twawaaay 4y ago
    Yeah... for some reason developers think that the higher position/salary requires them to put forward more complicated solution. Nothing further from the truth. My goal in life is to learn so that I can engineer systems and write code that is as simple as possible. It takes a bit of courage to put forward code that looks like everybody could write it -- which is exactly the point of getting more mature in software development. One problem I always had is that managers seem to reward people for how complicated projects they are working on rather than reward for putting in effort into making things simple. This makes a bit of conflict of interest but I personally resolved to do what is right and feel good with myself rather than to play the silly game of who can overcomplicate the project the most and still get away with it. Half the time the benefits of my approach become apparent after some time with the project -- the other half I don't get enough time or get a manager who doesn't want to understand where the productivity comes from.
- peltoche 4y ago
  Amen!
- sdeframond 4y ago
hkon 4y ago
Very nice. You don't need all of it for every project. But onion and dependency injection is my default setup.
orangehacker 4y ago
Can anybody point an important and successful system (preferably open source) that is built following Hexagonal, Onion, or Clean architecture?
- UK-Al05 4y ago
  Most places I've ever worked? They just not might not call it that. Onion architecture, vertical slice, ports & adapters, hexagonal architecture, clean architecture, functional core imperative shell. These are all very similar, and tends to get invented over and over again.
- simplotek 4y ago
  > Can anybody point an important and successful system (preferably open source) that is built following Hexagonal, Onion, or Clean architecture? Most of the projects I ever workers with either started off as DD+Clean/Hexagonal architecture, or were refactored to comply with those architecture styles. It's easy to understand why once you realize that those buzzwords are basically tags for a group of fundamental best practices that lead projects to become clear and easy to include changes.
- bcrosby95 4y ago
  Not a huge fan of trying to abstract out your ACID database, but other than that, I'm generally a fan and most of our systems roughly follow these sorts of architectures.
- drewcoo 4y ago
  It's so common that I was shocked to briefly work at a successful company with maybe 100 engineers and a code base that followed no consistent architectural rules and principal engineers that had never heard of the things listed in the article. I won't name and shame, but I shudder at the thought of all that organically-grown spaghetti.
- rileymat2 4y ago
  To expand on this, I have not looked for it, it may exist, but a deep dive into the high level design criticisms, benefits, explanation of its evolution in real open source projects would be really great. I should have probably gone to Google for this before posting, because it is one of those things that should exist, so it probably does. Edit: Maybe http://aosabook.org/en/index.html http://aosabook.org/en/index.html

93 points by sdeframond 4y ago

When I saw DDD, I was thinking the debugger, which is rather nice, but seems not to have been updated for well over 10 years https://en.wikipedia.org/wiki/Data_Display_Debugger https://en.wikipedia.org/wiki/Data_Display_Debugger

barbarbar 4y ago

When adding small features you end up jumping all over the place in all "layers". So a little change in controllers, services, repositories, entities. So I am not sure? This post mentions package by feature/component. But still seem to have this strict layered approach.

bayesian_horse 4y ago

I hate CQRS with a passion. Why would you do this to yourself voluntarily?

kmac_ 4y ago
Because there's no mixing of applying changes to the state of the system and retrieving the state. Testing becomes much easier and looks like a business DSL on the system (also connects well with functional core, imperative shell). Also for the heavy read systems you can easily introduce performance improvements as the read path is separated. Out of curiosity, what issues did you have with CQRS? How was it handled? I would like to know because maybe it was applied in an inconvenient way. Some developers that worked with classical layered architecture for years have a problem with CQRS, DDD and FCIS, but when it clicks it's "Oh wow, it makes a lot of things simpler" moment for them. There are also drawbacks of course and that approach fits well to bussines solutions, so you can't find many applications in OSS, which are mostly technical solutions.
- bayesian_horse 4y ago
  Oh I just prefer functional programming. Perfect testability. Also Django, while arguably not really FP is still perfectly testable, and not dealing with any of all of that. Why would I want to manage at minimum three classes for every endpoint? Maybe this has some justification in a situation with a couple hundred devolpers on software handling millions of dollars worth of stuff... but otherwise??

twawaaay 4y ago

Don't put it together. Learn all this stuff, understand it deeply. Then use it when you find it improves whatever you are working on. If you start putting it all together you will most likely only confuse other developers, especially juniors. Don't do it. The point of gathering all this knowledge should be making the application simpler and easier to maintain. So introduce stuff gradually and only when you find the added complexity pays out.

thdespou 4y ago
This is probably a syndrome of overhyped lead developers trying to "engineer" a solution without consulting with the team beforehand. They read a bunch of articles, decide that it's the "best" solution and blend everything together in a soup of tools that don't make sense. I've seen that happening many times with bad results every time.
- twawaaay 4y ago
  Yeah... for some reason developers think that the higher position/salary requires them to put forward more complicated solution. Nothing further from the truth. My goal in life is to learn so that I can engineer systems and write code that is as simple as possible. It takes a bit of courage to put forward code that looks like everybody could write it -- which is exactly the point of getting more mature in software development. One problem I always had is that managers seem to reward people for how complicated projects they are working on rather than reward for putting in effort into making things simple. This makes a bit of conflict of interest but I personally resolved to do what is right and feel good with myself rather than to play the silly game of who can overcomplicate the project the most and still get away with it. Half the time the benefits of my approach become apparent after some time with the project -- the other half I don't get enough time or get a manager who doesn't want to understand where the productivity comes from.
peltoche 4y ago
Amen!
sdeframond 4y ago

hkon 4y ago

Very nice. You don't need all of it for every project. But onion and dependency injection is my default setup.

orangehacker 4y ago

Can anybody point an important and successful system (preferably open source) that is built following Hexagonal, Onion, or Clean architecture?

UK-Al05 4y ago
Most places I've ever worked? They just not might not call it that. Onion architecture, vertical slice, ports & adapters, hexagonal architecture, clean architecture, functional core imperative shell. These are all very similar, and tends to get invented over and over again.
simplotek 4y ago
> Can anybody point an important and successful system (preferably open source) that is built following Hexagonal, Onion, or Clean architecture? Most of the projects I ever workers with either started off as DD+Clean/Hexagonal architecture, or were refactored to comply with those architecture styles. It's easy to understand why once you realize that those buzzwords are basically tags for a group of fundamental best practices that lead projects to become clear and easy to include changes.
bcrosby95 4y ago
Not a huge fan of trying to abstract out your ACID database, but other than that, I'm generally a fan and most of our systems roughly follow these sorts of architectures.
drewcoo 4y ago
It's so common that I was shocked to briefly work at a successful company with maybe 100 engineers and a code base that followed no consistent architectural rules and principal engineers that had never heard of the things listed in the article. I won't name and shame, but I shudder at the thought of all that organically-grown spaghetti.
rileymat2 4y ago
To expand on this, I have not looked for it, it may exist, but a deep dive into the high level design criticisms, benefits, explanation of its evolution in real open source projects would be really great. I should have probably gone to Google for this before posting, because it is one of those things that should exist, so it probably does. Edit: Maybe http://aosabook.org/en/index.html http://aosabook.org/en/index.html