What I Learned Building My First Clean Architecture Project in .NET

Mateus Rodrigues — Thu, 22 Jan 2026 23:40:13 +0000

TL;DR

I spent one month learning Clean Architecture (book + practice), built a small .NET project, and realized the biggest improvement is not “more folders”—it’s clearer boundaries and dependency direction.

Context

Hi! I’m a .NET developer (currently between junior and mid-level) working in the banking sector.
My team builds internal web systems (demand tracking, timesheets, dashboards).

This post is a short case study: what changed in my thinking after studying Clean Architecture and shipping a small project to GitHub.

My goal (one month)

I set a simple goal: learn Clean Architecture well enough to explain it and apply it.

My plan:

Read Clean Architecture by Robert C. Martin (Uncle Bob).
Build a small project to validate the ideas.
Document what I learned and what I would do differently next time.

Where I was coming from (MVC + “services” folders)

In my ASP.NET MVC projects, I used folders like Controllers, Views, and Services.
Inside “Services”, I often ended up with “query services”, “command services”, “access services”, and orchestration services.

It worked for small systems, but as projects grew, I noticed:

UI-driven design: business logic started depending on MVC and ViewModels.
Blurry boundaries: “Services” became a catch-all.
High coupling: UI changes often impacted core logic.

What Clean Architecture changed for me

The big shift was thinking in terms of boundaries and dependency direction.

In my project, I separated responsibilities into:

Domain: entities and business rules (the core).
Application: use cases, DTOs, and interfaces (ports).
Infrastructure: implementations (EF Core/Dapper, database access, external services).
Web: ASP.NET Core MVC (controllers, views, UI models, assets).

The key idea I internalized:
If tomorrow I need a different delivery mechanism (REST API, background worker, CLI), the core logic should remain the same.

Also, it helped me treat infrastructure as a tool.
EF Core is useful—but it shouldn’t dictate the domain model.

The project (WIP)

Repository: *https://github.com/mrodriguesweb/INVEST.Web*

It’s an investment tracker (work in progress) built with ASP.NET Core MVC + EF Core, applying Clean Architecture and DDD-style aggregates (e.g., tickers/stocks as aggregates).
The focus is maintainability, testability, and separation of concerns.

I also started experimenting with Docker to run the app + database + migrations/seed with a single command (still evolving).

Key lessons (so far)

Clean Architecture is not about “more layers”. It’s about clear boundaries and explicit dependencies.
Organizing around use cases is easier to evolve than organizing around framework concepts.
Keeping UI concerns out of the core improves reuse and testability.
A monolith can be fine—what hurts is an unstructured monolith with unclear boundaries.

What’s next

My next focus areas are cloud (Azure), microservices, and messaging—topics that frequently appear in interviews for remote backend roles.

If you have feedback on my structure or trade-offs, I’d love to hear it.

DEV Community: Mateus Rodrigues