CODEX
Introduction to Domain-centric Architectures (clean, hexagonal, …)
I recall struggling to understand clean and hexagonal architectures, so I wrote my explanation by resorting to evolving models resembling how we learn.
The hexagonal architecture (ports and adapters) is a must-know architectural pattern to separate the domain from the infrastructure. The onion architecture and the clean architecture introduce entities and use cases. All of these architectures are domain-centric — they’re derived from domain-driven design (DDD). I’ll present what I believe matters from each. Ultimately, we’ll conclude that you don’t need to use any of those as long as you're domain-centric.
The app
People and systems from the outside world interact with your app and vice-versa. This is our starting point. I’ll use the word app, but that can mean many things, from a device driver to a server-side rendered UI. In domain-driven design, it can represent a bounded context. Domain-centric architecture is not about physical architecture but instead about software design. As we'll see later, it boils down to decoupling the business domain from the technology.
