DEV Community: Miroslav Thompson

How unclear responsibilities add to technical debt on all levels of seniority

Miroslav Thompson — Wed, 03 Jun 2026 20:46:33 +0000

In IT management, governance, and leadership, it is perhaps more important than anywhere else that responsibilities are clearly defined for each role.

Relying on a person's seniority alone does not reveal how they will behave in situations with unclear responsibility. They will simply either not take responsibility or take it.

Most engineers cannot take a firm stance in situations of uncertainty. That's why they're engineers. In a situation of unclear responsibility, they take action that aligns with their overall psychology.

However, in IT, both choices statistically lead to an increase in your applications' technical debt.

Only an small fraction of people make the right choice in this situation.

Before I explain what that choice is, I need to talk about why decisions regarding responsibility lead to technical debt. And before you ask: Yes, even taking responsibility in unclear situations increases technical debt as well!

Lots of small things

Information technology is difficult across all domains. It is a demanding field where engineers and specialists must focus on a multitude of small yet critical details, from software development to security and cloud infrastructure.

Every day, the average IT engineer has to make hundreds of small choices, most of them interconnected across multiple layers. It is a mentally demanding job that requires a very high level of concentration... and we still produce bugs.

Our whole field is strange like that. Doing things well requires an immense amount of focus, yet if we look away for even a second, the entire industry collapses like a house of cards in a hurricane.

If engineers find themselves in a situation where it is unclear whether something is their responsibility, they will, in 99% of cases, choose to either take or not take responsibility—and you never know which it will be.

They are already making a high number of decisions during a normal workday; it is simply part of their job.

If you mix in uncertainty around responsibility, they will make decisions even if you, as a manager, don't want them to. This happens because the topic might actually be highly important business-wise, or it might be something that was overlooked by decision-makers. And often, it is.

Instead, the engineer ends up making the decision for you. The question then becomes whether that decision aligned with the goals of the company or the product they are building. Statistically speaking, 50% of those random decisions will not be aligned, thereby increasing technical debt.

The right action

In a situation of uncertain responsibility, the right thing to do is to bring the issue immediately to the decision-makers. Most engineers, however, will not do that, meaning that for the average company, technical debt is inevitable.

Make sure to discuss clear responsibilities with your engineers: what you expect from them, what they are currently doing, and what they should or shouldn't be doing. This is particularly relevant to:

SDLC
Delivery strategy
Dev / DevOps / InfraOps boundaries

Ethical considerations of working with Microsoft technologies

Miroslav Thompson — Sun, 31 May 2026 20:38:28 +0000

I’ve been working as a C# dev since 2010. I was 16 years younger back then, and the "ethical considerations" of anything were not really a topic I was interested in. I was young and stupid, but at least smart enough (or so I thought) to see that continuing my career in PHP and its related toolchains had no future.

Today, I am grappling with a question that every sane person earning a living by working with Microsoft technologies must ask: am I okay with this?

Big corporations are evil

If you thought this post was not going to get political, you thought wrong.

This is not a statement about Microsoft in particular, but a statement about the biggest corporations in the world.

It is not, however, a statement against capitalism and the free market. The counterarguments defending capitalism and the free market, I imagine, probably come from patriotic Americans who are sick in the head.

No, I’m not against capitalism and the free market—to an extent.

Economics teaches us that companies try their hardest to achieve a monopoly. It’s a logical conclusion and a well-researched fact, not something we have to moralize about. Companies compete to maximize profits and long-term economic rent.

But when you’re one of the biggest corporations in the world, you have more tools at your disposal. You break rules, you crush the competition, and you get involved in politics. All to achieve a monopoly. Anyone defending big corporations is either someone whose job is to do exactly that—like someone from PR—or someone insane.

Have you ever met someone like that? That 25-year-old woman from HR who convinced herself that her life finally has meaning because she works for JPMorgan? She worships the brand like it’s some sort of religion. And it’s not just a professional mask; it’s her own tragically neurotic personality maintaining the brand worship in her personal life as well. And she’s not alone.

On the other hand, there are people who refuse to touch anything MS-related. This was confusing to me at first—it’s software, just code, so what are you doing? What are you trying to prove?

Some people do this for the wrong reasons, like refusing to touch anything that isn't open-source, or simply avoiding anything MS-related because "MS is bad" because Steve Ballmer once shat on Linux, or because Word once crashed on them.
But those who do it for the right reasons have a point. Working with tools created by an evil entity means you are part of the problem.

But... what if I build the right thing with the evil tool? What if tools made by evil can be used for good? Is it really that morally wrong to use tools made by evil?

Maybe just a little. I mean, we’re in the software development world, not the weapons manufacturing industry, where the questions are much harder to ask and the answers much harder to find. I imagine someone from Heckler & Koch stumbling upon this article by accident, reading the heading, and chuckling at the absurdity of it.

Using Visual Studio, VS Code, programming in C#... yeah, those are tools made by an evil company. Using them means we are contributing to the success of that company.

Can I live with it? Yeah. But I’m not going to deny the fact that a tiny bit of my moral integrity is being suppressed for my own well-being and that of my family.

It's good

Now comes the opposite view.
The ecosystem of MS tools is just... good. Even worse, it’s the best I’ve ever worked with. And I’ve tried a lot of different ecosystems and toolchains: PHP, C, C++, Java, Python, Node.js...

Don't get me wrong, back in 2010, MS technologies sucked. We had WebForms—a website framework that was absolutely horrible to work with. Visual Studio sucked too. In 2026, it’s a completely different universe; MS sidelined the horrible black box called .NET Framework, making the new framework open-source and cross-platform.

Especially when combined with Azure, the entire MS ecosystem is just great to work with, and it has no equal. People who complain about MS stuff not working just aren't seeing the side of the software development world where MS is actually doing a lot of good.

It doesn’t change the fact that MS as a whole is evil—like a multi-headed hydra—but the head responsible for engineering toolchains, the ecosystem, and developer support is definitely a very good, well-behaved head.

Summary

MS is evil. Using tools made by MS means you’re contributing to their success. Denying this is stupid.
However, the ecosystem of tools is very good—probably the best. Denying this is also stupid.

DevOps for Developers: Reducing Cognitive Load and Boosting Transparency

Miroslav Thompson — Sat, 30 May 2026 20:21:20 +0000

For many developers, DevOps feels like unfamiliar, overcomplicated territory filled with tangled pipelines, cloud infrastructure nuances, and containerization hysteria.

But after working in this space for many years, I’ve realized that true DevOps isn't about forcing developers to become infrastructure gurus. Instead, it rests on two foundational pillars: maximizing transparency and minimizing cognitive load.

Achieving this requires close collaboration between development, infrastructure, and DevOps roles.

Let’s look at how to organize your code, repositories, and pipelines cleanly based on the architectural reality of what you are deploying.

Core Concepts

Deployable Blocks vs. Logical Applications

You must first understand the distinction between a deployable block and a logical application.

Deployable Block: A single, isolated technical unit that can be independently hosted or run. Examples include a single web API backend, a standalone website, a single-page application (SPA) frontend, or a native desktop app.
Logical Application: A logical grouping of multiple deployable blocks that work together to deliver a business solution. Typically, this means a backend API combined with the frontend SPA that consumes it.

Debugging Functional Pipelines is Extremely Time-Consuming

Unlike developers, a DevOps engineer doesn't have a debugger to see exactly which line of code is executing in real time. To verify that a pipeline works, they must trigger the run and wait for it to complete.

One Repository = One Deployable Block

Sticking multiple deployable blocks into a single repository significantly complicates your DevOps configuration. This leads to bloated, conditional pipeline configurations that are frustrating to maintain.

Instead, adhere to a clean rule: one repository per deployable block. Keep your API in its own repository and your frontend in another.

One Pipeline Definition = One Pipeline

One pipeline definition file must equal exactly one single pipeline. Do not write a pipeline definition that is reused across multiple deployable blocks; doing so is highly confusing and adds considerably to the total cognitive load.

One Pipeline = One Responsibility

Do not create pipeline definitions that rely on complex stage or job conditions to handle every single phase: pull requests, builds, deployments, and infrastructure provisioning. These pipelines are incredibly difficult to maintain.

The `env` Identifier

As a DevOps engineer, you need to identify which environments you use and consistently apply their correct identifiers—often referred to simply as an env.

Individual environments should be lowercase (e.g., dev, test, uat, or prod) because that is how engineers naturally speak in their daily vernacular:

"Which env has this bug?"
"Let's deploy to dev."
"How do we fix the bug on prod?"

Setting Up Pipelines

Pipeline Naming per Responsibility

Use this naming pattern for each pipeline:

{Deployable block name} PR for pull requests
{Deployable block name} BUILD for creating deployable artifacts
{Deployable block name} RELEASE for deploying to a specific environment
{Application name} INFRA for running IaC

Always use upper-case responsibility identifiers: PR, BUILD, RELEASE, and INFRA.

Reuse Pipeline Templates

Even though you should strictly follow the rule of having a single pipeline definition per pipeline per responsibility, the content of each definition can remain largely identical. You can achieve this by calling a reusable template across all the applications you manage.

Require the `env` for RELEASE and INFRA Pipelines

Both RELEASE and INFRA pipelines require a specific target environment to execute against, whereas targeting an environment makes no sense for PR and BUILD pipelines.

Identify the Correct Pipeline Set

Each deployable block has a pipeline set, but not all pipeline sets are created equal.

For backend APIs or server-side web applications, the correct pipeline set is:

PR: Runs automatically on pull requests to execute linters, check code health, and ensure the code compiles.
BUILD: Compiles the codebase from the chosen commit into a deployable artifact.
RELEASE: Takes that exact same artifact and deploys it directly into an environment that you choose manually when running the pipeline.

However, for SPA-like apps (and often native desktop apps), the situation is different. Because SPAs execute directly inside the user's browser, environment targets (like backend API connection URLs) generally must be compiled directly into the client-side bundle. Creating an environment-independent build artifact makes no sense here since the configuration is hardwired into the build itself.

Therefore, you should skip a dedicated build stage. The RELEASE pipeline does not consume a pre-compiled artifact; instead, it consumes a specific git commit directly, triggers the compilation for the chosen target environment on the fly, and deploys it immediately.

Understand the INFRA Pipeline

Application IaC (Infrastructure as Code) should not live inside individual application code repositories. Instead, maintain a separate Infrastructure Repository that contains the INFRA pipeline definition. The repository and the INFRA pipeline cover an entire logical application, not a single deployable block.

From an infrastructure perspective, it is much easier to wire up resource configurations in IaC within a single, unified place. This allows you to orchestrate the database, backend hosting, subnets, and the networking elements required to establish secure communication inside a Zero-Trust environment. It makes little sense to split your IaC into separate, disconnected repositories per deployable unit (such as a separate infrastructure repository for the backend and another for the frontend).

Like the RELEASE pipeline, running the INFRA pipeline strictly requires you to choose a target environment (dev, test, prod).

Local Run Versioning

Azure DevOps assigns an organization-wide, non-sequential tracking ID to pipeline executions called a Build ID, which is a number shared across all projects and pipelines.

Instead of relying on the Build ID, use a localized, incremental Pipeline Run Number (which can be implemented using the counter function in Azure DevOps). This is a simple, whole number that strictly tracks the executions of that specific pipeline, starting from 1 and incrementing with each run. It is human-readable, sequential, and cognitively effortless to cross-reference. This pipeline run number becomes critical later.

Setting Up Pipeline Run Names, Tags, and Metadata

At the start of a pipeline run, format the run name using a consistent pattern. For brevity, let's assume our deployable block is named MyApp:

PR pipeline: MyApp PR {PR run number}
BUILD pipeline: MyApp BUILD {BUILD run number}
RELEASE pipeline: MyApp RELEASE (BUILD {BUILD run number}) -> {ENV} ({RELEASE run number})
RELEASE pipeline for SPA apps: MyApp RELEASE {RELEASE run number}
INFRA pipeline: MyAppSuite INFRA {INFRA run number}

If your CI/CD tool allows it, expose this information within any configurable run metadata. The RELEASE pipeline naming conventions are particularly helpful for resolving a common developer complaint: "The pipeline broke something because it deployed the wrong version." (More on how to disprove this below).

DevOps-Compliant Applications

You cannot build a smooth delivery ecosystem if your applications operate as unreadable "black boxes". A piece of software must actively contribute to the clarity of the ecosystem as a whole.

The `stdout` Rule

From an operational perspective, your application operates in two entirely different states:

The Startup Phase: Everything executing before the application claims a socket from the OS and begins listening on a port.
The Running Phase: Everything executing after the socket is successfully opened and request processing begins.

The startup phase is critical. If your application encounters an exception here, hosting platforms will continuously spin and restart the instance in a loop. When a crash happens on startup, the runtime state of absolutely everything is unknown—including your logging libraries.

You cannot rely on logging sinks (like Application Insights or Serilog) to tell you what went wrong. If the logging provider initialization itself causes the crash, it will fail silently and leave you completely blind.

During the startup phase, write everything exclusively to standard output (stdout). A pure console log is completely bulletproof. It ensures that if a boot-up crash occurs, a DevOps engineer can immediately open the container logs or cloud log stream, read the plain-text exception, and isolate the bug instantly. Save your sophisticated external telemetry sinks for the running phase after the socket is safely open.

Configuration and secrets

Configuring your applications should never involve logging into a production server to manually edit files. That is a recipe for configuration drift and unmitigated chaos.

The Environment Variables Rule

Every application must be built to read its configuration values directly from environment variables. Only local development machines are allowed to use files for tracking configuration changes in got depository.

Cloud platforms natively expose environment variables in a highly transparent, easily adjustable UI. If you need to test a configuration change, you update the variable in the platform portal, restart the instance, and immediately see if it works.

What About Secrets?

Secrets (connection strings, API keys, etc.) are fundamentally just configuration values, but they require a Zero Trust delivery model. They absolutely do not belong in git.

To handle secrets cleanly without introducing cognitive overhead:

Masking in Variable Groups: Use your CI/CD tool’s secure variable groups (like Azure DevOps Variable Groups marked with the lock icon). Once entered, they can never be viewed again by users, and the pipeline output will automatically mask them.
Key Vault Reference Architecture: Have your DevOps engineer set up a central Key Vault. Use a Managed Identity for your application instance, granting it strict read-only access to the vault.

The Version Info Endpoint

Every hosted deployable block should expose a public, unauthenticated JSON endpoint at /version-info that returns a payload structured like this:

{
  "env-file": "dev",
  "env-server": "dev",
  "started": "2026-05-30 13:44:51",
  "uptime": "2d 1h 35m",
  "buildPipelineRun": 811,
  "releasePipelineRun": 875,
  "infraPipelineRun": 44,
  "buildPipelineUrl": "https://dev.azure.com/your-org/your-project/_build/results?buildId=13466",
  "releasePipelineUrl": "https://dev.azure.com/your-org/your-project/_build/results?buildId=13799",
  "infraPipelineUrl": "https://dev.azure.com/your-org/your-project/_build/results?buildId=7987",
  "sourceCommitHash": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0",
  "sourceCommitBranch": "main"
}

The `version-info.json` File

Before diving into individual properties, let's look at how the version-info.json file behaves.

This file should live in the repository of all deployable blocks and always deploy alongside your production artifacts. The values inside the source code repository are left as empty strings or zeroes, except for env-file, which defaults to the string value local.

`env-file`

This property is explicitly overwritten by the RELEASE pipeline to match the target environment selected during execution.

Sometimes, developers are permitted to deploy a build directly from their local machines to lower testing environments. The presence of "env-file": "local" in an environment provides an immediate visual signal that this was a local deployment, not an automated pipeline run.

`env-server`

Each deployable block running in a specific environment must have a scoped environment variable named env that identifies the environment (such as test, uat, or prod). The /version-info endpoint should surface this variable's value here.

When managing a vast catalog of applications and fluid infrastructure, you aren't always in control of the underlying hostnames or DNS masks. Having the application explicitly report its active env-server value gives you immediate, definitive confirmation of the environment in which the application is actually executing.

`started` and `uptime`

These values apply primarily to server-hosted applications and are incredibly useful when diagnosing infrastructure instability or unexpected restarts.

The `pipelineRun` and `pipelineUrl` Properties

These properties expose the localized pipeline run number mentioned earlier.

Surfacing these values will save DevOps engineers thousands of headaches. When a developer claims, "The pipeline deployed the wrong version because my feature isn't working," you can easily verify the deployment status. Simply navigate to the embedded pipeline URL, check the sequence number, identify who ran it, and correlate it directly with the running application's state.

OpsBuild.net

Would you like the idea of having a complete, opinionated dev/DevOps/InfraOps environment ready?

Visit https://opsbuild.net/ and subscribe to the mailing list.

Building software in C#: part 2 - code architecture

Miroslav Thompson — Fri, 29 May 2026 19:52:31 +0000

In my previous post, I described how historical trends shaped our (or at least my) perception of software architecture.

However, with experience and seniority, you learn that code architecture always depends on a variety of context-dependent factors. This is something AI cannot help you with. A human must always establish the direction, depending on human factors such as company culture, team dynamics, formalization of work, responsibilities, and the software life cycle.

The best code architecture I have encountered so far doesn't have a name yet. It is a mix of various concepts taken from different architectural patterns.

Domain as a Flat List of Functions

When you use the mediator pattern, you are basically using a service locator. Writing CreateUserCommand and CreateUserCommandHandler is fundamentally the same thing as writing ICreateUserService and/or CreateUserService with a single CreateUser method.

Ultimately, the specific approach doesn't matter. The important thing is to always write your domain as a flat list of functions, each having a single responsibility and handling a single process. Time and again, this has proven to be the best strategy to guarantee long-term stability and, all else being equal, the avoidance of technical debt.

In this article, I will use the term function, but what I mean is a mediator command/handler or a service with a single public method; the specific shape is secondary.

CQRS, But Read is Part of the Domain

Originally, CQRS was meant to separate reads and writes at the infrastructure level because, for most business applications, 90% of operations are reads and 10% are writes. Domain writes are focused on one system, and changes eventually become visible eventually in a separate system optimized for reading.

However, I have never worked in an environment where traffic was high enough to justify such infrastructure-level optimizations. One reason is that the Czech Republic is a relatively small country with a population of around 10.5 million, and not everyone works at a high-traffic site like seznam.cz.

From a code architecture perspective, accounting for a separate read-only database is difficult. You need to produce and capture events, and you must maintain a manual or automated synchronization mechanism in case event delivery fails. Chances are, you don't need to do this at all—I certainly haven't.

BUT: Separating your domain functions into writing and reading functions is still an excellent idea.

Why?

If your users interact with a UI that displays data, then reading data is part of your domain. The DDD purists who believe the domain is strictly for writing are mistaken. The domain is supposed to represent what the business needs. If the business needs to read and display data, a function that reads and returns that data belongs in the domain.

Higher-Order Functions

Once you start writing your domain as a list of read or write functions, if the domain is complex enough, you will inevitably need a higher-order function: a function that calls (reuses) other functions in your domain. This is a saga pattern of sorts. Your first higher-order function will be a second-level function reusing your foundational, flat list of functions.

The critical architectural constraint here is that any higher-order function must strictly read from or write to the domain using the functions directly below them. A second-level function can use the first-level (bottom) list of functions. A third-level function can only use second-level functions, and so on.

Another constraint is that functions on the same level must NEVER invoke each other.

I have never needed anything higher than a second-level function, even in highly complex financial domains. However, in my first job, I worked on a monolithic application for travel agencies, which was probably the most complex domain I have ever seen. If that domain were written using this architecture, it would definitely require third- or even fourth-level functions.

Monolithic Domain

The domain is a monolith that should not be modularized within the scope of a single application or API. You should never spread domain functions across different .csproj files. The only justification for moving functions elsewhere is a deliberate decision to extract a new application that takes over specific responsibilities from the original one.

Validation, Transformation, Dependency

These are the only three actions allowed inside your domain functions, executed in any order:

Validation: Verify whether, at any point inside the function, your in-memory data is valid.
Transformation: Transform or manipulate data in memory.
Dependency: Invoke a request to an external service (including your repository) to pass data, request data, or both.

Direct Use of EF Core

Most applications I have written in my career use MSSQL as their primary data source, or at least some relational database.

Time for a hard-to-swallow pill: switching from one RDBMS to another never happens. Unless the database schema is cleanly architected from the beginning, moving from MSSQL to PostgreSQL or MySQL (or vice versa) requires an immense amount of work that is rarely justified.

For those reasons, I don't see a point in abstracting the DbContext. It already is the abstraction I need. The argument that you must abstract DbContext into a repository interface just for testing is outdated; the ability to mock or substitute it has been solved for years. If you think EF Core is inherently slow, you probably haven't heard of .AsNoTracking().

This is also my critique of the Unit of Work pattern in Clean Architecture—it is often completely useless. There is no point in abstracting DbSet<User>.Add into IUserRepository.Add only to invoke IUnitOfWork.Commit instead of DbContext.SaveChanges(). YAGNI!

Dependencies as Modules & Maturity Levels

The domain needs to handle operations other than just reading and writing to the database. You invoke external APIs, write PDFs to file systems, or open sockets using legacy, third-party binary protocols.

Some operations are simple enough to write directly inside the function. However, complex operations should be abstracted away into an interface (like IInvoicePdfWriter) with the actual implementation moved elsewhere.

Where exactly? It depends on how much architectural overhead you are willing to accept:

Maturity Level 5: InvoicePdfWriter is packaged inside a NuGet package, making it completely reusable across other projects.
Maturity Level 4B: InvoicePdfWriter resides in a dedicated .csproj file created solely for this specific functionality.
Maturity Level 4A: InvoicePdfWriter resides in a shared .csproj for all external dependencies, organized in a dedicated folder. A custom analyzer is configured to allow or forbid dependencies the same way you would use project references.
Maturity Level 3: InvoicePdfWriter is in the same .csproj as the domain functions, but the functions inject the IInvoicePdfWriter interface.
Maturity Level 2: You skip the interface entirely and inject the concrete InvoicePdfWriter class directly.
Maturity level 1: The dependency speficic code is written directly inside of your function. You should at least move all of that to an internal service (maturity level 2).

The difference between 4A and 4B is practical: with 4B, you can easily end up with hundreds of .csproj files even for a relatively small project. This slows down your Visual Studio instance considerably and is rarely worth the overhead.

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.

Microservices!

Containers! Kubernetes!

This wasn't really a code architecture trend but infrastructure one, but it affected our perception of how we should build things. Splitting everything into separate service solidified the idea of strong domain. Now every individual domain part has its own application that communicates with other parts very tightly over the network.

At around the same time GRPC was popularized to make the network communication more efficient.

This was such a strong trend it made everyone think on how their applications can be split into microservices, without considering the costs of doing it and the costs of maintaining it.

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.

Modular monolith

At one point we found out that blindly building everything around microservices and containerizing everything is not a good idea and that running a monolith, for majority of companies out there, is cheaper, sane and simply the right decision.

But this time we know there are much better approaches to code, such as vertical slicing, but we're calling them modules now.