Herberto Graça

I have been following hexagonal architecture recently, found some good references, * This article https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexa… have detailed explanation on the components of hexagonal architecture. * There is COLA framework https://github.com/alibaba/COLA based on spring boot from Alibaba. Description is in Chinese but google translate does good enough translation. There is some pretty interesting things happening in Chinese universe that are hidden for language barrier. * Another sample application in .NET https://github.com/kgrzybek/modular-monolith-with-ddd which gives good overview of code architecture.

I presume you haven't read the "blue book"? Because that covers many of what you ask. In addition, the canonical (but not clearest, IMO) source on Hexagonal architecture is by the "inventor" himself: https://alistair.cockburn.us/hexagonal-architecture/. Several links in that article are dead now, but some still work and point to excellent discussions and articles. If you are looking "war stories" or "case studies" especially in a setting where management or colleagues need some convincing, this article of how Netflix employs it might help https://netflixtechblog.com/ready-for-changes-with-hexagonal-architect… I've -depressingly, actually- found that often people are easier convinced by an argument "BigCorp™ does it too" than by "its good because of X". Recently a more practical post landed on HN. It includes CQRS, which might make it more convoluted than what you need, but even with that, it has some really nice "lessons learned" and "best practices": https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexa… (ninja-edit: weird sentence fixed)

Based on my years of experience in working with a millions-of-locs over decades codebase: Be aware of the abstraction fallacy: developers are often guided by this insane notion that they can get rid of accidental complexity by wrapping it away behind an abstraction layer. You can't. It's better to suck up to the complexities of the existing system, and prefer explicit, procedural copy-and-pasting than trying to invent your own abstraction layer on top. The problem with the after-the-fact abstraction layer is that if the original team members are not available, you are likely not in possession of the whole theory of the software. Hence it is not likely you can in the beginning choose the right abstractions. The correct way - if possible - to simplify existing code is to refactor the code itself. The specific anti-pattern you will reach by following the false abstraction strategy is the lasagna architecture: https://herbertograca.com/2017/08/03/layered-architecture/ Two literary works that helped me enormously to grok working with legacy code and programming in particular: * Peter Naur's paper "Programming as theory building" - this was an amazing eye opener to me. It specifically highlights several problems that may arise when working with legacy code when the original developers have left the building. * Michael Feathers: Working Effectively With Legacy Code - not to be read necessarily as a "how to" recipe book, but rather as a collection of philosphies and…

Both terms are from The Mythical Man Month. Are you saying Plan 9 is over-engineered and bloated? https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://herbertograca.com/2018/11/19/11-plan-to-throw-one-away/ https://en.wikipedia.org/wiki/Second-system_effect

Interesting. I'd like to think that, most probably, your job exists and is funded because those folks (and you) "got shit done" for the last 20 years. In my experience (around 2 decades also), when it comes to small/medium projects, spending a bit of effort separating business logic from UI/database/server code is wise up to a certain point. If the effort doesn't add too much code and layers of indirection, then fine. However, DDD/HexagonalArch consultants tend to add soo much boilerplate and layers of indirection between between an HTTP request and a response that it becomes detrimental to productivity. For example take a look at this article: https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexa… Specially this part (but the entire article is a gem): > This means that Dependency Injection and Dependency Inversion are not enough to decouple components, we will need some sort of architectural constructs. We might need events, a shared kernel, eventual consistency, and even a discovery service! Respectfully I'd like to think that it is satire. But it isn't. With events your code is no longer linear. Stuff happens with triggers (events) that are not clear at first glance unless you fully understand the entire stack. Shared kernel is just a place to shove interfaces under the carpet and pretend code is no longer coupled because you added extra 2 layers of indirection (interfaces and kernel) between 2…