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

https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

by sdeframond • 4 years ago

93 40 4 years ago

twawaaay6• 4 years 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.

Akronymus2• 4 years ago

As a junior who previously got thrown into the deep end on one project, where I have been essentially useless for way too long, but now am having actual guidance, and do one part at a time: I can only second that.

Also: train your juniors, please. Getting thrown into the deep end REALLY hurts the speed of learning.

Bjartr• 4 years ago

What would you say good training for juniors should look like.

skrtskrt• 4 years ago

Imo when it’s done well it doesn’t look like complexity at all and makes it simpler, not more complicated, even if there are more “layers”

twawaaay6• 4 years ago

In my experience, when people look for a way to include something in the project it almost always results in more complexity.

A question like "how do I put it all together" signals focus on tools rather than focus on the product. When developers learn new things they frequently look for opportunity to use them. This preoccupation with the tool they just learned usually happens at the cost of the product. They are looking for a way to add things to the project rather than look for ways to remove unnecessary things.

The right state of mind for architect/designer is to seek learning/understanding paradigms, tools, technologies, etc. to have a library of solutions for when they are needed and be able to recognise when it is the right time to do it, not to try to find a way to use something they just learned.

hkon2• 4 years ago

These are established and well known patterns. Better other people get to learn them sooner. The seasoned developers have probably experienced the problem they solve and the juniors might be saved from doing the same mistakes as others have before them.

The argument that juniors will have a hard time understanding it can be said about anything you don't like / don't want. And then you can begin to lay it on thick. It's a convenient scape goat for sure.

thdespou• 4 years 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.

twawaaay6• 4 years 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• 4 years ago

Amen!

sdeframond• 4 years ago

As stated in the main schema in TFA:

Understand all of this, but use only what you need.

hkon2• 4 years ago

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

orangehacker2• 4 years ago

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

rileymat2• 4 years 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

orangehacker2• 4 years ago

I asked this question, because I do have doubts they exist. Especially, any modern one.

These architectures were introduced around 20 years ago to address technical shortcomings of enterprise systems at that time.

Quoting the original article on Hexagonal architecture (https://web.archive.org/web/20090327032122/http://alistair.c...), the motivation was to address those 3 problems:

- First, the system can’t neatly be tested with automated test suites because part of the logic needing to be tested is dependent on oft-changing visual details such as field size and button placement;
- For the exact same reason, it becomes impossible to shift from a human-driven use of the system to a batch-run system;
- For still the same reason, it becomes difficult or impossible to allow the program to be driven by another program when that becomes attractive.

Is any of the above a real pain in the project that you are building in 2022?

I very much doubt it is. And if it's not, then introducing such an architecture will bring more harm than benefit.

There were some interesting discussions on that topic lead by Martin Fowler few years ago: https://www.martinfowler.com/articles/badri-hexagonal/

falkensmaz33• 4 years ago

They exist. They are locked behind the firewalls of corporate America and Europe, and their engineers are generally forbidden to discuss it in public. OSS developers don't build software this way. Primarily because most generally useful (and therefore successful) OSS is not business domain-centric, and does not benefit from these patterns.

As one of those engineers that's forbidden to talk in public, I can assure you these patterns are extremely useful to keep valuable software viable, extensible, and maintainable for 15+ years. I just can't drop any specifics because IP lawyers are assholes.

fruit2020• 4 years ago

What do you do in a code base 15 years old?

rswail• 4 years ago

I can't show you, but if you travel in Bangkok and use LINE Pay, then you're using one.

Combination of CQRS, event sourcing and kafka.

And I agree with falkensmaz3, they definitely do exist and they work much better in terms of defining the business domains and the way(s) the business "Nouns" interact with each other.

UK-Al053• 4 years 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.

simplotek2• 4 years 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• 4 years 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• 4 years 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.

jmclnx• 4 years 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

barbarbar• 4 years 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_horse2• 4 years ago

I hate CQRS with a passion.

Why would you do this to yourself voluntarily?

kmac_• 4 years 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_horse2• 4 years 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??

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

Related Stories