Это неизбежно. Постоянное изменение требований предметной области отхреначит любую архитектуру, которая была разработана изначально. Потому что разные требования рождают разные модели и агрегаты, с которыми надо работать. И в какой то момент модель у вас превращается в агрегат. Или какие то агрегаты делятся в модели и другие агрегаты. Разработка проекта с требованиями "сейчас" плевое дело. Попробуйте только проект такой поддерживать лет 10. Посмотрим, как издержки на бесполезном рефакторинге, который не даёт выигрыша в архитектуре, а только даёт сделать хотя бы саму задачу, сожрут все бюджеты. И выгоднее будет с нуля написать.

@@foxesfox5870 Да, полностью согласен с тем, что требования меняются, и это может разрушить любую архитектуру, если не предусмотреть гибкость с самого начала. Но, на мой взгляд, архитектура не должна быть набором жёстких рамок, как это часто бывает с готовыми структурами. Она должна быть скорее набором принципов, которые можно адаптировать под новые условия. Важно не просто следовать шаблону, а понимать, почему определённые решения принимаются. Ведь цель архитектуры - это не только решить задачи «сейчас», но и обеспечить возможность долгосрочного развития и изменений, не съедая бюджеты на рефакторинг. Да, поддерживать проект на протяжении 10 лет сложно, но именно поэтому архитектура должна быть гибкой и эволюционировать вместе с проектом. Если изначально выбрать слишком жёсткую структуру, то переписывание с нуля действительно может оказаться более выгодным вариантом. Однако, хороший проект всегда балансирует между адаптивностью и строгостью

@@34shadows так она тут и не жёсткая. Верно, набор принципов, договоренностей. Никто не мешает обмазать скелет MVC какими то условностями. С FSD так же. Единственное по сути ограничение любой архитектуры это формат работы с зависимостями проекта. Здесь он строгий, как и в mvc, mvvm, паттерне cqrs и прочих. Гибкость проекта в том числе зависит от качества моделей и агрегатов, которые вы собираете. И я бы сказал, в бОльшей степени от этого, чем от разбивки папок. Но прикол в том, что надоело от проекта в проект видеть разные подходы, видеть мусор в каких то папках, не понимать, куда пихнуть очередной компонент. Это как раз и решает fsd. Стандартизация. Готовое сообщество, а не какая то команда конкретного проекта.