На HolyJS был еще один доклад про FSD от Евгения Паромова, в котором Женя разобрал 3 недостатка на основе рабочего опыта работы с методологией на разных проектах, и как их можно решать путем переосмысления слоев. Было бы конечно круто нам прямо на конференции провести дебаты, но я после своего доклада был настолько выжат, что сил ни на что практически не осталось. Но в будущем возможно что-нибудь подобное и организуем. Доклад был довольно крутым и по контенту, и по подаче. Когда его выгрузят на ютуб, всем, кто использует FSD, рекомендую посмотреть (пока доступна только преза). Но указанные проблемы мне все же хочется разобрать. 1️⃣ Огромное количество сущностей и фичей в проекте. Это можно встретить на многих проектах, построенных на FSD, так как большое количество слоев «заставляет» декомпозировать все на отдельные сущности и фичи, и даже группировка по связанной функциональности не помогает. Важное правило которое я со временем понял, что не все сущности/фичи заслуживают место в глобальном неймспейсе, в нем должны находится только самые важные для проекта слайсы. Если фича не переиспользуется, то очень вероятно, что она может быть заинлайнена внутрь сущности (например, авторизация или логаут в сущность пользователя, или добавление товара в корзину в сущность корзины). Мы у себя все базовые сценарии храним рядом с сущностью, а новые продуктовые фичи добавляем в слой features (с фич флагом, что бы в будущем можно было без особых затрат фичу выпилить). 2️⃣ Widgets + Features + Entities = High Coupling. Здесь проблема схожа с предыдущим пунктом, когда единый модуль (слайс) пытаемся разбить по различным слоям и получаем высокую связанность (или если быть точнее - destructive decoupling). Решается она через local-first подход, когда все держим локально внутри слайса до тех пор, пока это не понадобится где-то еще. Кортима FSD довела эту идею до абсолюта, предложив изначально все хранить на уровне слайсов страниц и теперь подход page-first является приоритетным при разработке согласно методологии. 3️⃣ Entities не позволяет описать бизнес модель. Тут поинт в том, что на слое сущностей у нас запрещены кросс импорты и приходится работу со связанными сущностями выносить на верхлежащие слои. Ранее это и правда было проблемой, но сейчас это решается через фичу @x, которая разрешает кросс импорты. Женя подметил, что в сущностях есть UI, кросс импорты которых часто приводят к циклическим зависимостям. Но FSD в этом плане гибкий, и на уровне сущностей мы можем вообще не использовать UI, спустив его на другие слои и используя как слой domain из чистой архитектуры. И что важно, разрешая кросс импорты методология не отказывается от инверсии зависимостей через DI. 4️⃣ Изменчивый shared. Тут проблема в том, что shared состоит из конкретных реализаций (api, UIKit) и все другие слои зависят от него, что в чистой архитектуре ui/инфра выносятся на самый верхних слой и не влияют на низлежащие слои путем работы через абстракции. Но тут есть два момента. Первый, мы пилим фронтенд и полностью абстрагировать тот же UI от модулей, где есть бизнес-логика обычно не имеет никакого смысла. Второй, к сожалению это присуще всем приложениям на любой архитектуре, если изначально плохо реализовать общие UI-компоненты, data-слой и другие shared-модули, то это приведет к сложному рефакторингу в будущем всего проекта. Я эту проблему вижу по другому. Слой shared в FSD - это по сути единый модуль (слайс), в котором нет никаких правил. И если приложение обрастает инфраструктурой, то зависимости внутри между различными модулями (условно менеджер модальных окон и ремоут конфиг) могут быть неявными и запутанными. Мы для решения выделили отдельный слой для инфраструктурных сервисов (тоже с правилами кросс-импортов), а тот же UIKit изначально был вынесен в отдельный пакет монорепы (что позволило его изолировать от бизнес-специфичных кейсов).