Сегменты

См. также: Слои и архитектура для детального описания каждого слоя.

Описание

Сегменты – это внутренняя структура модуля (слайса), определяющая ответственность каждой части кода. Каждый сегмент имеет четко определенное назначение и следует принципам high cohesion (связанные вещи вместе) и low coupling (минимум зависимостей между сегментами).

MUST

Структура сегментов

Каждый слайс должен содержать только следующие сегменты:

Сегмент	Назначение	Пример
ui	UI-компоненты и стили	article-card.tsx
model	Состояние, бизнес-логика, типы	article.types.ts, use-article.ts
api	Сложные API-операции с доменной логикой	atomic-update.ts, batch-operations.ts
lib	Утилиты конкретного слайса	slugify.ts, format-date.ts

Правила размещения кода

MUST

• Следовать диаграмме принятия решений при добавлении нового кода
• CRUD операции (get, create, update, delete) размещаются только в shared/api/endpoints/
• Каждый файл должен иметь единственную ответственность
• Имена файлов в формате lower-kebab-case

Сегмент api — специальные правила

MUST: Использовать сегмент api только для сложных доменных операций:

• Атомарные обновления с rollback
• Batch-операции с транзакциями
• Сложная оркестрация нескольких API-вызовов с бизнес-правилами
• Операции с доменными инвариантами

FORBIDDEN

• Размещать CRUD операции в entities/*/api/ или features/*/api/
• Дублировать простые API-вызовы из shared/api/endpoints/ в слайсах
• Создавать дополнительные сегменты (например, hooks/, types/, constants/, helpers/)
• Группировать код только по типу файлов – нарушает принцип Locate из LIFT
• Использовать анонимные названия файлов:
  • ❌ styles.ts
  • ❌ index.module.scss
  • ❌ types.ts
  • ❌ hooks.ts
  • ✅ index.ts (только как Public API)

MAY

• Не создавать сегмент, если он не нужен в конкретном слайсе
  • Например, простая entity может содержать только model/ и ui/
  • Feature без UI-компонентов может содержать только model/ и api/
• Использовать Public API (index.ts) для экспорта элементов сегмента

Диаграмма принятия решений

Используйте эту схему при добавлении нового кода в слайс:

Детальное описание сегментов

📁 ui/ — UI-компоненты

Содержит:

• React/Vue/другие UI-компоненты
• CSS/SCSS модули и стили
• UI-тесты компонентов

Примеры:

entities/article/ui/
├── article-card.tsx
├── article-card.module.scss
├── article-list.tsx
└── article-preview.tsx

Принципы:

• Компоненты должны быть презентационными
• Бизнес-логика вынесена в model/
• Имя файла отражает суть компонента

---

📁 model/ — Бизнес-логика и состояние

Содержит:

• TypeScript типы и интерфейсы
• Хуки (custom hooks)
• Stores (Zustand, Redux, MobX)
• Доменные правила и валидаторы

Примеры:

entities/article/model/
├── article.types.ts
├── use-article.ts
├── article.store.ts
└── article.schema.ts

Принципы:

• Единственный источник правды для доменной логики
• Типы должны быть строго типизированы
• Хуки начинаются с use-

---

📁 api/ — Сложные доменные операции

⚠️ Важно: Не путать с shared/api/endpoints/ для CRUD!

Содержит:

• Атомарные операции с rollback
• Batch-операции
• Оркестрация нескольких API-вызовов
• Операции с доменными инвариантами

Примеры:

entities/order/api/
├── atomic-update.ts       // обновление с откатом
├── batch-operations.ts    // массовые операции
└── complex-checkout.ts    // сложный checkout процесс

---

📁 lib/ — Утилиты слайса

Содержит:

• Вспомогательные функции конкретного слайса
• Форматтеры
• Парсеры
• Специфичные валидаторы

Примеры:

entities/article/lib/
├── slugify.ts
├── format-reading-time.ts
└── parse-markdown.ts

Принципы:

• Не содержит бизнес-логики
• Чистые функции (pure functions)
• Переиспользуемы внутри слайса