Clean Architecture in .NET, without the dogma

Clean Architecture gets cited like scripture and applied like a checklist. After years of shipping .NET Core systems that other people maintain, I have a more pragmatic view: the goal is replaceable edges and a protected core, not a folder for every noun.

Protect the core, not your ego

The point is that business rules should not depend on the database, the web framework, or any third-party SDK. When I integrated OpenAI, DeepSeek, and Ollama behind a single interface, swapping providers became a configuration change rather than a rewrite. That is the real payoff.

Boilerplate is a cost, spend it deliberately

Not every CRUD endpoint needs three layers of abstraction. I reserve the full pattern for the parts of the system that genuinely change — integrations, pricing, domain rules — and keep simple things simple. Architecture should reduce future cost, not inflate present cost for its own sake.

Repositories and the EF question

A repository over Entity Framework can be redundant — EF is already a unit of work. I add one when I want to hide query complexity or keep the domain ignorant of the ORM, and skip it when it would just be a pass-through.

Takeaway

Use Clean Architecture as a tool for managing change, not as a rulebook. Protect what changes, keep the rest simple, and your future self will thank you.