DDD ASP.NET Почему не удобно для больших проектов с более чем 30 реестрами #dotnet #aspnetcore #ddd Анализ причин, по которым классический DDD в связке с ASP.NET и EF Core становится проблемой в проектах с более 30 реестрами: тяжёлые агрегаты, горы спецификаций, транзакционные и навигационные боли. Предлагается прагматичный выход — гибридный подход с применением DDD только в ядре и более простых паттернов на периферии. 🧱 Тяжёлые агрегаты: строгий принцип "один запрос — один агрегат" ведёт к множеству Include/ThenInclude и монструозным SQL с десятками JOIN — даже простое обновление поля заставляет загружать весь граф. ⚠️ Взрыв спецификаций: папка Specifications разрастается до сотен классов, их сложнее композировать, они завязаны на IQueryable и плохо переносимы в другие инструменты (Dapper, gRPC). ⚙️ Проблемы транзакций: Scoped DbContext и Unit of Work подходят для малых систем, но бизнес‑кейсы требуют изменения нескольких агрегатов — либо уход в распределённые механизмы (Saga, Outbox), либо нарушение DDD. 🗂️ Навигация и скорость разработки падают: при 30+ реестрах изменения простой сущности затрагивают 10–15 файлов, растёт время на онбординг и релизы. 🚀 Рекомендация: оставить DDD для сложных доменных зон, а для периферии применять CQRS, Vertical Slices/Feature‑Sliced подходы и более прагматичные модели — архитектура должна помогать бизнесу, а не быть самоцелью. https://habr.com/ru/articles/1015124/ @aStateOfNet