.NET
Why I Think Beginners Should Learn Clean Architecture
I used to drop my DbContext straight into controllers and dump logic into Program.cs. It worked, until I had to change something. Clean architecture is what fixed that.
When I first started coding in .NET, my only goal was getting stuff to work. I'd drop my database context straight into my API controllers, write validation checks right next to my SQL queries, and dump half my logic into Program.cs. It worked. The app ran, the JSON returned, and I felt like I knew what I was doing.
Then came the first time I had to change something.
I tried to swap a database library and update a business rule on the same day. Half my endpoints broke. A tweak to an order calculation somehow affected my user registration logic. I was spending most of my time untangling code I'd written two weeks earlier instead of writing anything new.
That mess is what pushed me to look into clean architecture.
At first it felt intimidating. Everyone talking about it sounded like they were reading from an enterprise textbook, throwing around terms like dependency inversion and domain-driven design. But once I actually started breaking my .NET solutions into proper layers, something clicked.
How I actually structure it now
When I start a project, I set up the Domain layer first with pure C# classes, no Entity Framework, no HTTP, no third-party packages, just the business logic on its own. Then the Application layer handles the actual use cases, defining interfaces for what it needs, something like "fetch a user" or "send an email," without caring yet how those things actually happen.
Only after that's in place do I touch EF Core or ASP.NET. Database contexts and external APIs go in Infrastructure, and the Minimal APIs or Controllers go in Presentation.
What actually changed day to day
SOLID principles stopped being interview answers and started being how my project folders are already set up, not something I have to remember to apply on top.
Testing stopped being a headache. Business rules that don't know anything about a database can be tested with xUnit in seconds, no in-memory database, no elaborate mocks, just the logic on its own.
Tech stack lock-in stopped worrying me. If I swap SQL Server or change an email provider, only Infrastructure changes. The core application doesn't notice.
Where I still keep it simple
There are still times to skip all of this. A basic CRUD app that could be a couple of files doesn't need four separate projects. But going through this shift changed how I think about code generally: from throwing syntax at the wall until it works, to building something meant to actually hold up when I need to change it later.