I'm curious about the hexagonal architecture section

[cstorey]

Hi, I really appreciate you writing this up – it's really well described.

Is it possible to share some examples of the extra complexities you've found with hexagonal architecture? My guess is that maybe you've found that always defining a domain-side interface for infastructure to be too much of a pain, and sometimes allowed your domain to depend on infra. Is tht what you mean, or something else?

[zakirullin]

Hi there, thanks for the feedback!

sometimes allowed your domain to depend on infra

No, that's not the case, keeping the infra independent is a good thing, although also debatable and context dependent.

In that kind of architecture one spend too much time thinking about things in "technical perspective" or, in terms of horizontal technical layers. Whereas what matters more is "vertical slices" perspective (modules/components), that's to say - isolation of concerns.

For small services/projects the hexagonal architecture is an overkill, even though it might feel proper/fancy. The thing is that at a small codebase (let's say less than <1K LoC) it doesn't matter what kind of architecture you pick - be it Even Sourcing or Hexagonal architecture. Things will work anyway, and despite excessive complexity would be quite maintainable (at least by the authors), given the small size of the application.

Whereas for large-scale applications it shifts so precious focus from isolating business functionality to the thinking in terms of horizontal layers. One might say that we can keep focus on isolation (vertical slices), whereas maintaining hexagonal-like layering inside a given vertical slice. But we have a limited mental capacity to spend. It would be mentally taxing to keep both at a good level.

Also, that kind of architecture has a high bar to entry. The sheer number of files is somewhat tripled. Other people (especially non-developers) can't use the codebase as a source of knowledge any longer, because they see all these "ports/adapters/in/out/domain/context/kernel" folders which don't contribute to the understanding of the project. A lot of gluing code, and you have to jump across the layers of abstractions here and there to get to the gist.

Also, we had some discussion here:
#7

[cstorey]

Hi,

Thanks for for the reply. I think we might be talking about slightly different things though:

The onion architecture variation I know implies using layers like: domain model, domain services, application services, infrastructure. Which is more layers than you described.

My understanding is a akin to mpszczolinski's. Namely, just that you'd have driving side (eg: a web server handler) and driven side (eg: a database adapter / repository) that both know about the domain's interfaces, and the domain your business logic) is just kinda sandwidged in the middle, not caring that much about the rest of the world. If you've not seen it, you might find Alistair Cockburn's description interesting.

You can go for a a full layered ("clean") architecture approach within that scope, but to my mind the ports/adapters approach can scale as far down / up as you need it it to.

Honestly, I think half the problem when talking about things like this is that terms tend to be subject to semantic diffusion–this might be anatural property of language, but it doesn't half make things confusing :)

Thanks,

[zakirullin]

Sure, I've read Alistair's work. As well as Jeffry Palermo's blog series, even though it is "Onion Architecture", but nevertheless the idea is all the same. Not only I read, but I adopted these architectures back in the early days. Years passed, and I never used it again - for the above mentioned factors. Not only it concerned me - people across different companies and teams came to the same conclusions.

You can examine the source code of some open source projects, be it Kubernetes, or something as widespread as that. You won't find Hexagonal architecture there. It's not some fundamental principle that is good to follow. It doesn't bring anything new to the table.

We have always had the dependency inversion principle - "High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces)". All other derivatives - Hexagonal/Onion/Clean architecture add more levels of taxonomy and structure to the code, which is not always practically justified.

[dormeiri]

I liked this section, however I think that the issue is even more rooted. I think it is more about the balance between freedom and standards.

The good thing about such architecture is its ability to become a standard, which helps when you interact with multiple services. Being familiar with the standard would help you getting familiar with the code.

However, over-standardization may lead to detours and anti-patterns where things are not aligned with the standard, requiring you to 'glue' the solution to fit it. Also, to perform a refactor you not only need to understand the code, but also the standard.

From my experience, it is helpful to standardize layers that aid navigation through the service and its non-code dependencies and consumers, while also allowing freedom in the domain logic.

[ov7a]

Totally agree. Patterns do reduce cognitive load. I'd prefer having ugly, but uniform code structure(s) instead of lots of beautiful snowflakes. But of course, balance is important.