Building software in C#: part 1 - history.

Miroslav Thompson — Thu, 28 May 2026 20:29:09 +0000

3-Layer Architecture

When I started programming in C# back in 2010 in Prague (Czech Republic), the dominant trend was the 3-layer monolithic architecture. This approach splits an application into a presentation layer, a business layer, and a database layer.

For some reason, however, this concept was often misunderstood. Instead of layers, people treated them as independent components that could talk to each other "whenever it made sense." Senior developers during interviews would strictly insist that the business layer must sit precisely between the presentation and database layers, and that you must never communicate directly from the presentation layer to the database—or, God forbid, vice versa.

The bizarre legacy projects where the UI and the database communicate directly with each other in both directions, while the "business layer" serves merely as a dumping ground for helper code "when things get too complicated," date back to this era.

Onion Architecture

Some time later, the Onion Architecture technique became popular. Developers got incredibly excited about it—after all, software is never just about three simple layers, right? That would be too easy. Software is complicated, like life itself, so it needs many layers. Therefore, this had to be the correct approach.

In the center of the onion is the core—the ultimate root of your business and the very center of everything. Everything on top of it consists of technical layers that stack up sequentially. These outer layers aren't considered important; only the center matters.

It sounded so good on paper that teams rushed to put it into practice, inadvertently creating immense technical debt for future years to come.

To this day, the practical implications of the "onion" model remain vague. If you search Google Images for "onion layer architecture," you will find wildly different and conflicting interpretations. Is the center of the onion your business logic or the shape of your database entities? Can layers that touch communicate in both directions? What is the outermost layer actually supposed to be?

Domain-Driven Design (DDD)

I suspect that Domain-Driven Design (DDD) gained popularity because people were overemphasizing the importance of the Onion Architecture's "core." The "core" represented the vital part: the business logic.

DDD became very explicit about this: the "domain" is the holy grail of your business. As a developer, you are expected to step back and prioritize the business logic above all else. You act as a translator of business requirements into code, and nothing more. This is DDD—business first!

So, how do we implement it? Well, you need a domain expert—a dedicated role responsible for maintaining the ubiquitous language of the domain and translating business goals into requirements.

In my entire career, I have never met anyone who officially held the title of a domain expert. Never, even in highly formalized multinational corporations, have I seen this role officially established. (Though some rumored they actually had them at Netflix).

Ultimately, this approach often circled back to implementing a standard 3-layer architecture, just doing it correctly this time. The domain served as the business layer, and the data flow moved strictly in one direction: from presentation to business, and then to the database. As for background processes, WSDL SOAP APIs, or webhooks—we just pretended they fit cleanly into the onion so the codebase wouldn't turn into spaghetti. Are you hungry?

DDD, ES, and CQRS

For a time, this combination was the ultimate trend that suddenly made everything look pristine and perfect.

You isolate your holy grail business core into an immutable stream of changes called event sourcing (ES). Your domain remains pure and spotless. Your classes represent domain objects in a perfect 1:1 relationship with the business, and their methods reflect real-world business processes.

CQRS (Command-Query Responsibility Segregation) made the whole setup feel like an encounter with programming perfection. Commands are sent straight to your domain, while queries are handled by read models constructed asynchronously from events. Because, let’s face it, "eventual consistency" is a beautiful concept.

It worked beautifully until someone asked a fundamental question: "How do we ensure user email addresses are unique?"

This simple requirement made some architects so defensive they argued back: "That's a stupid requirement, you don't actually need unique emails, go away."

But seriously, how do you handle this in a pure DDD/ES/CQRS setup?

You cannot easily enforce it inside a User class because that class only knows the context of a single user. Do you create a UserCollection class in front of your commands to manage emails? If so, how does a UserCollection capture the meaningful business knowledge that DDD advocates so strongly for?

Furthermore, how do you validate uniqueness across a collection if you rely on event sourcing to load your domain state? Loading every single historical email into memory to run a check is clearly inefficient. You are left with no choice but to store user emails separately, outside of the primary event store.

This highlights the biggest drawback of the DDD/ES/CQRS paradigm: extreme complexity. Managing snapshots, command/event versioning, data anonymization (for GDPR) within the event store, event ordering, concurrency, and read-model desynchronization means you often spend more time engineering a starship than shipping production-ready features.

MediatR

Not long ago, MediatR and the mediator pattern gained massive popularity in the C# ecosystem. Suddenly, applications were structured around commands, notifications, and interfaces like IMediator, ISender, or IPublisher to build request pipelines.

Developers, likely exhausted by the overhead of DDD/ES/CQRS, looked for something simpler.

MediatR helped many realize that treating the "domain" as a flat list of distinct, single units of work is highly maintainable, predictable, and clean.

Clean Architecture

Looking at our industry's history, the name "Clean Architecture" itself highlights how deeply developers crave perfection. It often feels like the field is driven by an ongoing effort to prove architectural points.

In reality, Clean Architecture is essentially a modernized 3-layer architecture split across five or more projects. It leverages the mediator pattern and offers a structured separation of concerns that—once you gain experience with it—makes it highly obvious where every piece of code belongs.

Vertical Slicing

Vertical slicing shifts the focus toward the componentization of your code. Instead of organizing your project by technical layers, you group code by distinct business features, ensuring each folder contains all the layers relevant to that specific functionality.

For example, instead of scattering a feature across a UserRepository (in a data project), a UserService (in a business project), and a UserPage.razor (in a UI project), you place them all into a single User folder. Everything related to users lives in one place.

This approach delivers excellent modularity. It is arguably one of the best ways to build single-server web applications or UIs, though it requires careful boundary management when designing complex APIs.

DEV Community: Miroslav Thompson