Комментарии 4
Архитектура — это набор правил о трёх вещах: где лежит код, какие части от каких могут зависеть и насколько дорого будет что‑то изменить в будущем.
Здесь главная проблема всех этих горе архитекторов, поехавших умом на тебе названий директорий, переменных и бесконечных попыток абстрагироваться от всего на свете.
На серьезных проектах как только речь начинает заходить о производительности то какая-нибудь Чистая архитектура очень быстро превращается в тыкву. Или например, нужно сменить БД и неожиданно выясняется что не смотря на вагон абстракцией это невозможно сделать просто и нужно очень много чего переписывать. Ну или классика, на какой-нибудь большом проекте приходит осознание что код просто невозможно читать т.к. функционал в 5 строчек кода растянут на 15 классов в 5 слоях.
после морочения мозгов всеми этими религиями пришёл к тому что делаю самую простую гибридную архитектуру EF + smart DTO (DDD) -> DAL -> BL -> API/UI + переиспользуемые сервисы в различных проектах, по сути smart DTO и есть DDD, сменить базу не получится никогда, и не должно получаться, там разные особенности, проще написать миграцию для конкретных баз чем тратить усилия на то что никогда не произойдёт, если база нормально спроектирована с максимальным количеством constraints и чёткой структурой то это уже само по себе 90% успеха, тестирование без моков на реальной базе сэкономит кучу времени, smart DTO позволят переместить значительную часть интеграционных тестов в unit, никаких интерфейсов без необходимости, только если они реально где-то используются, по возможности прямое управление, никаких медиаторов и прочих камней в свой огород которые перемещают ошибки времени компиляции в ошибки времени исполнения, любой такой горбец обойдётся в часы отладки прода при отсутствии ошибок в локалхосте. если долго смотреть на девушку то можно увидеть как она выходит замуж, такие overengineered архитектуры помогут вашим конкурентам вывести на рынок рабочий продукт пока вы строите бумажные домики из справочников по чистой архитектуре. каждое лишнее усложнение принесёт лишние часы работы при самых простых задачах. ИИ здесь это самое глупое решение которое можно использовать - увеличить кодовую базу которую придётся поддерживать и тестировать, а самое главное - ПОНИМАТЬ, чего ИИ никогда не будет делать за вас. архитектура должна быть минимальна, простейшая для данной задачи с extension points. иначе проект может вобще никогда не запустится из-за переусложнения. все эти излишества приносят потребность в лишних членах команды которых можно вобще не нанимать если быть проще и не выпендриваться. те программисты которые ценят деньги клиента и немного думают о бизнесе и щитают экономику практически никогда не используют переусложнённые подходы. на похоронах проекта который умер от нехватки финансирования на 80% готовности будет смешно разговаривать о гипотетической смене базы данных
N‑tier это немного о другом. Каждый tier в N‑tier архитектуре должен быть реализован при помощи чистой, многослойной или какой-нибудь другой архитектуры. N‑tier - это solution architecture, а другие типы архитектуры из этой статьи - это application architecture.

N‑tier, Clean Architecture и Vertical Slice: практическое сравнение для.NET