Обновить notes
All checks were successful
CI/CD Pipeline / docker (push) Successful in 40s
CI/CD Pipeline / deploy (push) Successful in 6s

This commit is contained in:
2026-04-03 20:02:01 +03:00
parent cba311d78e
commit 073fc6507f

25
notes
View File

@@ -126,3 +126,28 @@ src/shared/
Это действие пользователя с логикой? features/ ↓ Это действие пользователя с логикой? features/ ↓
Привязан к бизнес-сущности? entities/ ↓ Привязан к бизнес-сущности? entities/ ↓
Абстрактный UI без бизнес-логики? shared/ui/ — Абстрактный UI без бизнес-логики? shared/ui/ —
И еще размышлений
Что у нас по факту
Мы взяли FSD и добавили:
- Слой Layouts — каркас страницы
- Слой Screens — контент страницы с локальными компонентами
- Правило scope — компонент живёт максимально близко к месту использования, и поднимается на уровень выше только при переиспользовании
Это не FSD в чистом виде. Но и не что-то принципиально новое.
Существующие названия
Feature-Sliced Design (FSD) — то от чего отталкиваемся, но расходимся в деталях.
Screaming Architecture (Robert C. Martin) — структура проекта "кричит" о том, что он делает. Открываешь screens/knv/ui/ — видишь КНВ. Открываешь widgets/ — видишь глобальное. Это близко к нашему подходу.
Colocation Principle — держи код рядом с тем, где он используется. Именно этот принцип отличает нас от FSD: page-specific компоненты лежат внутри screen, а не в глобальном widgets/.
Как назвать
Я бы не стал придумывать новое название. Это:
> FSD с принципом колокации (FSD + Colocation)
Или проще — адаптированный FSD. Суть отличия укладывается в одно правило:
> Компонент живёт на самом низком уровне, где он используется. Поднимается выше только при переиспользовании на 2+ страницах.
Если хочется краткое название для внутренней документации — можно SLD (Scoped Layer Design), подчёркивая что каждый компонент привязан к scope (shared → entity → feature → widget → screen → layout → page).