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.
If the business still exists and is continuing to evolve 15 years later, why shouldn't the code base?
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.
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?
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.
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.
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
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/
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.
You don't need hexagonal architecture to test the code api.
Layered architecture will do the job!
It sounds like you don't do much, if any, professional work.
> These architectures were introduced around 20 years ago to address technical shortcomings of enterprise systems at that time.
No, not really, and your personal assertion completely misses the whole point of DDD or any software architectural style you mentioned.
The whole point is to keep software flexible and accommodating of change, and in the process reflect a set of very basic software design principles that avoid/eliminate problems such as circular dependencies or testability.
> Is any of the above a real pain in the project that you are building in 2022?
Again, you don't seem to have much if any professional experience. UI testing, or any type of testing involving UI work either directly or indirectly such as accessibility/localization or any end-to-end test in general, is still an unsolved problem and a bane of software engineers.
Nevertheless, your comment reads like a strawman. The main benefit, and the whole point, of layered architectures is to ensure the software architecture to simplify modifying/updating the bits that change very frequently and stabilize and minimize the need the fundamental bits that only rarely need to be touched. UIs tend to be the part of an application that is updated the most, thus it makes all the sense in the world to adopt a software architecture which handles UI as a separate external component which minimizes or eliminates both fan-in, and turns fan-out to be a non-issue by depending on abstract interfaces whose concrete implementations are injected. These are not dad's from the 1990s,these are fundamental software engineering concerns.
I didn't mention DDD.
> a set of very basic software design principles that avoid/eliminate problems such as circular dependencies or testability.
You don't need hexagonal architecture to achieve that.
How is hexagonal architecture superior for building modern web applications vs for example vanilla Rails?
Why successful projects like discourse, hacker news are not built following this architecture?
Why you never hear stories of how hexagonal architecture helps companies like Google, Facebook, Microsoft, or Apple build great software?
> The main benefit, and the whole point, of layered architectures is to ensure the software architecture to simplify modifying/updating the bits that change very frequently and stabilize and minimize the need the fundamental bits that only rarely need to be touched.
The thing is - "onion/hexagonal/clean" architectures and "layered architecture" are not the same things.
Of course layers are fundamental - nobody questions them. What I do question, are 3 mentioned architectures.
For example MVC is also a layered architecture, and in many cases it works great. It allows the same level of testability as hexagonal architecture, but with less boilerplate and indirection. It is great for building websites like this forum.
I won't name and shame, but I shudder at the thought of all that organically-grown spaghetti.