4 ms·

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
- deleted 4y ago
  [deleted]
- orangehacker 4y 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.cockburn.us/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/ https://www.martinfowler.com/articles/badri-hexagonal/
  - UK-Al05 4y ago
    To this day automated tests suits against UI tends to be flaky. So testing against a code api is indeed better. Most of this stuff is just developing against interfaces, and having that interface owned by the business code. All infrastructure code implements those interfaces. Business code code doesn't get polluted by technical infrastructure stuff. It's easy swap out databases, etc Always a good idea. Functional core, imperative shell is also a modern term for this.
    - orangehacker2 4y ago
      > To this day automated tests suits against UI tends to be flaky. So testing against a code api is indeed better. You don't need hexagonal architecture to test the code api. Layered architecture will do the job!
falkensmaz3 4y 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 4y ago
  What do you do in a code base 15 years old?
  - falkensmaz3 4y ago
    The same things you do in a code base 3 years old. We've just made it fashionable to evolve a code base until we hit a wall, toss it in the trash, and start over with the next "modern" tech that will eliminate the problems of the previous code base. Rinse/repeat. If the business still exists and is continuing to evolve 15 years later, why shouldn't the code base?
- rswail 4y 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.
  - orangehacker2 4y ago
    I asked specifically about "Hexagonal, Onion, or Clean architecture". CQRS is another story, it is relatively widely used and very handy in certain scenarios. Is LINE Pay designed in a form of some kind of onion 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

deleted 4y ago
[deleted]
orangehacker 4y 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.cockburn.us/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/ https://www.martinfowler.com/articles/badri-hexagonal/
- UK-Al05 4y ago
  To this day automated tests suits against UI tends to be flaky. So testing against a code api is indeed better. Most of this stuff is just developing against interfaces, and having that interface owned by the business code. All infrastructure code implements those interfaces. Business code code doesn't get polluted by technical infrastructure stuff. It's easy swap out databases, etc Always a good idea. Functional core, imperative shell is also a modern term for this.
  - orangehacker2 4y ago
    > To this day automated tests suits against UI tends to be flaky. So testing against a code api is indeed better. You don't need hexagonal architecture to test the code api. Layered architecture will do the job!

falkensmaz3 4y 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 4y ago
What do you do in a code base 15 years old?
- falkensmaz3 4y ago
  The same things you do in a code base 3 years old. We've just made it fashionable to evolve a code base until we hit a wall, toss it in the trash, and start over with the next "modern" tech that will eliminate the problems of the previous code base. Rinse/repeat. If the business still exists and is continuing to evolve 15 years later, why shouldn't the code base?
rswail 4y 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.
- orangehacker2 4y ago
  I asked specifically about "Hexagonal, Onion, or Clean architecture". CQRS is another story, it is relatively widely used and very handy in certain scenarios. Is LINE Pay designed in a form of some kind of onion architecture?