Если говорить об FSD как о полноценной архитектуре фронтенд-сервера, то она хорошо подходит для небольших проектов. Если проект крупный, то каждый из уровней превращается в свалку компонентов, особенно entities и features.    Я в одном из объемных проектов чтобы этого не происходило просто создал внутри компонентов директорию с дочерними комполнентами, которые используются только в нём, и также разделил их на FSD-уровни, с сохранением однонаправленности.    Но ощущение костыльности этого решения не исчезает. Проект пишем на React и те же React Context или Portals  уже не вписываются в парадигму архитектуры

Самое ценное для меня в FSD: однонаправленный поток данных и правило публичных api для слайсов. Соблюдение этих требований уже дает порядок, а дальше - корректно разбивать на виджеты/фичи и т.д. Тут чаще всего возникают вопросы, т.к у всех разное понимание 🙂

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

Мне понравилось с этим возиться, видно потом картину, но скорость замедляется из-за всех обсуждений и дискуссий. Есть еще люди, которые начинают виджеты засовывать в виджеты. Каждый запрос и кнопку кидать по фичам, получается очень много папок. Не все могут понятным образом разделить бизнес-логику и отображение. Короче нужна жесткая рука в этом деле, опытный разработчик. А методология всего лишь направление :)

Буду рад прочитать потом статью 😎

Опа, холиварчик 😊