3 архитектурные ошибки в C#, из-за которых проект становится неуправляемым

Когда проект молодой, писать «всё в одном классе» кажется быстрее. Создать отдельный интерфейс, вынести слой — это же лишняя минута! Но эта минута потом стоит часов: код невозможно покрыть тестами, замена ORM превращается в переписывание бизнес-логики, а новый человек в команде тратит день только на то, чтобы понять, где в методе заканчивается выборка из базы и начинается бизнес-правило.Эти антипаттерны не привязаны к версии фреймворка — они встречаются и в legacy на .NET Framework, и в современных проектах на .NET 8. Покажу три конкретных примера из реальных проектов — и как их исправить.