There's maybe 20 companies in the world that benefit from this kind of architecture. Everyone else is just being an architecture astronaut or inventing for invention's sake.
I disagree, the company I work for is big but not massive and yet even using this kind of approach on a single product in our suite has been really beneficial. Its not as complicated as you may think, its just about keeping the code clean. Its allowed us to refactor technical implementations with much less risk and makes the code easier for people to follow. Sure it maybe a bit of a mental shift, but its not like you wont find benefits in it. (And I disagree with the insinuation that its more complex or slowing down development, I actually find the opposite is true).
Well - apparently mine is one of them. Most of software we do, was built on some variation of DDD. Most of it is not very huge - maybe couple hunderds LOC.
Spliting it in managable hunks, that can be modfied independently and do not depend on framework, libraries and other 3rd party code minimizes headaches greatly, when customers want to overhaul some part of the business processes.
From time to time, someone says "it's to complex" which tipically means "Framework I like has this opaque feature which saves me two hours of work and you don't allow me to use it". Yet in the long run math is clear.
Of course it is tool and should be used for the right job. If something is CRUD, just use your favourite CRUD generator and do not pretend you need rocketship.
you make a good point to keep things simple, "solve the problem you actually have not the one you wished you had". But, many of these ideas can have advantages even in small scale contexts. In some contexts they're not wins (e.g. extreme performance requirements might be prioritised over cost of future change) but in most situations where the cost of abstraction is negligible they're not a bad idea.
e.g. i've seen a gigantic technical mess created in a small company with less than a dozen staff -- that required a year of engineering effort to remediate -- because the application code of the company's product was not written to decouple the product's internal domain model from the external format controlled (and changed) by the first customer.
You're a 100% right with that example, I just think it's important to pry these apart as separate issues. The issues you faced should've been solved by a simple data transformation at the system boundary. "Don't let external data formats permeate through your codebase" is, to me at least, basic engineering intuition. There's no deeper meaning to be gleamed from that, the team lead displayed gross incompetence and now you have to clean up his mess.
On the other hand, these "clean architecture" blogs paint this ungrokkable colossus as a northstar -- they contrast it with issues like yours, and present this as the cure to every problem you've ever had in software. I just don't think that's true. None of these blogs ever highlight the loss of understanding. As you approach this style of engineering, you have so many layers, dependency injections and "oh and btw also this" style cross-cuts that no single use-case i.e. codepath can be understood by single person. You're just writing small units of code and hurling them at the codebase, hoping they enter the black hole's orbit and do what you want them to. I like to think that's why Uncle Bob uses huge, unexplorable celestial bodies for book covers :)
P.S. as a counterpoint to your example, I work at a company that's infatuated with the idea of microservices, with little consideration of the tradeoffs involved. A while back I had to add a feature to a new microservice that had been a few months in production. After a couple of weeks of wading through the ports and adapters, DDD-inspired architecture, I realized two things: one, this "service" is just exposing CRUD operations on a single database table with zero business logic in the middle. And two, the Data/ORM adapter layer of the architecture does not work. The migrations are never executed, the DB entities are never mapped, and SQL queryies never fire. Looks like nobody used it since it was first deployed :)
Messes are obviously bad but I dont think these patterns are the answer. They typically balloon the amount of code in exchange for nothing more than a bit of consistency and the ability to write some fairly hollow unit tests.
Hexagonal works where you have a big solid core of complex stateless business logic but thr fact that it's very common to NOT have this and hexagonal presents itself almost as a panacaea makes me hate it a little bit.
