Which software architecture is right for us?
This is a question I often get from fellow architects and customers.
There is indeed quite some guidance out there: Hexagonal Design, Clean Architecture, Imperative Shell, Domain Driven Design, Model View Controller, Model View ViewModel, Model View Presenter, just to name a few... and it is hard to make a choice.
But it is the wrong question to ask.
Think AND not OR
Instead of considering which guidance to rely on, consider what aspects each of these can bring to your architecture.
Each of them brings the notion of IO to the boundary as a guiding principle
- Domain Driven Design teaches us to root the meaning of the core pattern in the business language (and bounded context).
- Clean architecture teaches us to model and expose the domain as a use case (I prefer the term business capability) instead of an entity based model.
- Imperative Shell teaches us to design the core pattern in a functional way
- Hexagonal design brings the concept of explicit ports (contracts) to the table.
- etc...
So, think AND not OR... these sets of guidance are not mutually exclusive.
None are suitable as a top level architecture
None of the architectural guidance is, ironically, suitable for use as your top level architecture.
No matter which variation you pick, when you apply it at the system level it will still result in a big ball of mud (distributed or otherwise).
The mental model that works best (in my opinion) is to base your architecture on the business capabilities that your organization posesses.
Splitting up a code base this way will result in a unique architecture that is aligned naturally along the same axes that make your business unique.
Once you have these natural boundaries in place as your top level architecture, you can (and should) apply the guidance that makes sense inside each of the respective capabilities.
