February 10, 2026

Always use Clean Architecture even if you don't need it.

Clean Architecture it's overused and loved in .NET community, the more you master it, the easier it will be to work.


Clean Architecture (CA) has become a widely adopted and beloved standard in the development community. Even if it doesn’t make much sense to use it in some cases, every developer should get familiar with it. At the end of the day, what dominates the industry almost always becomes the rule, regardless of whether you agree or not.

Even for simple CRUDs

Throughout my career, I’ve always worked on projects with over-engineering—projects that were just 4 pages of tables with CRUD operations but had multiple layers of abstraction. That’s why I advise: don’t rely on simple solutions for personal or small projects; instead, use what is dominant in the industry, like Clean Architecture. When you really need it, you’ll be ready to perform with over-engineering or even pass a tough interview.

The value of what is socially dominant

The main point is: it’s not just about what makes technical sense, but also about what is socially dominant in the industry. Learning and mastering Clean Architecture means you’ll be prepared for when your manager throws you into a sprint board with dozens of tasks in a system full of over-engineering and tight deadlines.

Mastering is better than resisting

Even if you are building a simple CRUD in .NET, it’s worth structuring the project following Clean Architecture. This way, you gain practical experience with something that challenges developers of all levels.

Ready for any challenge

Once we tackle a complex feature within a system using Clean Architecture, we soon deal with responsibilities of each layer, such as making a user entity in the domain work with Identity and EF Core without making the domain layer depend on NuGet packages. The earlier we solve these challenges, the less stuck we get in the future.

People who say they are against live in another reality

In reality, most developers don't choose the architecture of the systems they work on. Software engineers at the lower levels of the hierarchy usually don't make those decisions they follow the direction defined by technical leadership.

At some point in your career, you will probably be assigned to a project that uses Clean Architecture without any necessity. That is simply how the industry works.

I remember once being assigned to a very complex microservices project built around Clean Architecture and everything else Kubernetes, DDD, Vertical Slice, Event-Sourcing. This is not unusual. Many large tech companies adopted certain architectural patterns, and eventually the rest of the market followed.

You might go through an interview process with hundreds of candidates just to join a project that is heavily over-engineered. At that point, you are there to deliver software not to challenge the architectural decisions. That is the reality of the software industry.