How many times have we heard someone say, “Oh, come on, we’ll never need to change the database of our application!”
And then… it happens. Just like it can happen that you need to replace an external provider, a third‑party service, or an entire integration API.

So how can we keep these kinds of changes from becoming a nightmare? The answer lies in well‑designed abstractions.

In this session, I’ll share a few stories from my past. Stories where, thanks to Hexagonal Architecture, I managed not only to drastically reduce the impact of radical changes, but also to make an application usable across different contexts and for different clients, without having to rewrite it every time.

During the talk, we’ll explore:

- why embedding external dependencies directly into our code can become a serious medium‑ to long‑term problem;
- what Hexagonal Architecture really is, and how it differs from Clean Architecture and Onion Architecture;
- some real‑world cases where Hexagonal Architecture proved crucial for saving a project, enabling experimentation, and reducing development time.

Examples will be in .NET, but the principles and patterns discussed apply to any programming language.