The Case: A 500,000-line legacy application where every controller has 20 dependencies and a single bug fix takes 3 days of regression testing.
We started by identifying the 'High Value' logic. We moved the most critical business rules into a new **Domain** project. We didn't change the database yet; we just isolated the logic from the EF Core DbContext using interfaces.
Instead of trying to refactor the whole app at once (which always fails), we took ONE feature (e.g., 'Submit Order') and implemented it from scratch using Clean Architecture. We used **MediatR** for the new feature while letting the old features stay in the legacy controllers. This is the 'Strangler Fig' pattern.
Over 6 months, we slowly moved feature by feature. The test coverage went from 5% to 85%. Deployment frequency went from once a month to daily. The team's morale skyrocketed because developers could actually understand the code they were working on. Architecture is a marathon, not a sprint.
Q: "When is refactoring to Clean Architecture worth it?"
Architect Answer: "Refactor when the cost of maintenance is higher than the cost of development. If your team is spending 80% of their time fixing bugs and only 20% building features, your architecture has failed. Clean Architecture is an investment in your team's future sanity and the long-term survival of the business."