Uploaded February 2026 | Updated September 2026, 2 weeks ago
Domain-centric? Why Hexagonal and Onion Architecture Are Answers to The Wrong Question – And What To Ask Instead by Oliver Drotbohm
To separate technical from domain code, architectural approaches like Hexagonal or Onion Architecture are currently all the rage. However, discussions about their semantic details and their mapping to the source code structure of software projects are at least equally ubiquitous.
How much abstraction and mapping between architectural concepts is needed? Is persistence metadata in the domain model heresy? Above all: what is the actual goal of the exercise, and: does it have to be so complicated?
We address these and other questions in a theoretical overview and by looking at concrete examples. We discuss the trade-offs of different approaches and how various tools and libraries help us to maintain the intended structural integrity.
Domain-centric? Why Hexagonal and Onion Architecture Are Answers to The Wrong Question – And What To Ask Instead by Oliver Drotbohm
To separate technical from domain code, architectural approaches like Hexagonal or Onion Architecture are currently all the rage. However, discussions about their semantic details and their mapping to the source code structure of software projects are at least equally ubiquitous.
How much abstraction and mapping between architectural concepts is needed? Is persistence metadata in the domain model heresy? Above all: what is the actual goal of the exercise, and: does it have to be so complicated?
We address these and other questions in a theoretical overview and by looking at concrete examples. We discuss the trade-offs of different approaches and how various tools and libraries help us to maintain the intended structural integrity.
![[VDBUH2026] George Patrașcu - Ports, Adapters, and Other Ways to Stop Breaking Your Business Logic](https://i.ytimg.com/vi/UIlFFBZKSaA/mqdefault.jpg "[VDBUH2026] George Patrașcu - Ports, Adapters, and Other Ways to Stop Breaking Your Business Logic
Your business logic shouldn’t care whether it’s talking to a SQL database, a Kafka topic, or a REST API — but in most codebases, it does. In a microservice architecture, this coupling becomes especially painful: as services evolve and API versions change, you end up touching business logic just to keep up with infrastructure churn.
In this talk, we’ll explore Hexagonal Architecture (Ports & Adapters) as a practical answer to this problem.
We’ll start with the “why”: not to dismiss traditional layered architectures — they solve real problems, and it’s the model we use across many of our own services — but to examine the specific caveats that emerge as systems grow.
Where does coupling infrastructure concerns to business logic start to hurt? Hexagonal Architecture doesn’t throw layering out the window; it refines it, offering targeted solutions to those exact pain points. From there, we’ll walk through the core concepts of the pattern — ports, adapters, and the application core.
But this won’t be a textbook walkthrough. Everything you’ll see is grounded in real production experience. We’ll share the challenges we ran into, the mistakes we made, and the tradeoffs we had to navigate — including the pragmatic vs. dogmatic decisions that come up constantly in practice (should your ORM bleed into your domain model? It depends).
You’ll leave with:
– A clear mental model of Hexagonal Architecture and when it’s worth reaching for
– Concrete code examples of ports and adapters in action, written in C#
– Different approaches to structuring your project (and when to choose each)
– An honest look at the tradeoffs — including when not to use this pattern
Whether you’re building a new service or wrestling with an existing one, this talk will give you practical tools to make your business logic more resilient, testable, and independent of the infrastructure around it.")
