Skip to content

Выбор структуры data

Структура должна помогать читать код, а не демонстрировать заранее выбранный шаблон.

Быстрый выбор

txt
несколько связанных файлов
→ плоский slice

один домен, несколько независимых сценариев
→ flow-first

слишком много файлов одной роли
→ технические подпапки

1. Плоский slice

Для обычного списка постов:

txt
data/posts/
  posts.schema.ts
  posts.dto.ts
  posts.mapper.ts
  posts.store.ts
  posts.types.ts
  index.ts

Это предпочтительный старт.

2. Несколько flows одного домена

Если posts разрастается на независимые сценарии:

txt
data/posts/
  list/
    list.store.ts
    list.types.ts
  details/
    details.store.ts
    details.types.ts
  editor/
    editor.schema.ts
    editor.store.ts
    editor.types.ts
  index.ts

Не делите по flows, пока эти сценарии не имеют собственной логики и lifecycle.

3. Технические папки

Для большого редактора может быть удобнее разделить файлы по техническим ролям:

txt
data/post-editor/
  model/
    post-editor.store.ts
  types/
    post-editor.types.ts
  schema/
    post-form.schema.ts
  mapper/
    post-form.mapper.ts
  index.ts

Техническая папка появляется из-за количества файлов, а не потому что «так положено».

Если slice небольшой, те же файлы можно оставить плоско:

txt
data/post-editor/
  post-editor.store.ts
  post-editor.types.ts
  post-form.schema.ts
  post-form.mapper.ts
  index.ts

Главное правило: если технические папки уже появились, *.types.ts не кладите в model/. Для типов используйте отдельную types/.

Что можно хранить в model/

model/ — группа для реализации состояния и поведения:

  • *.store.ts;
  • *.vm.ts;
  • другие файлы, которые относятся к state/model implementation.

Типы и интерфейсы хранятся отдельно в types/.

Не создавайте абстрактный post.model.ts, если его роль непонятна.

Алгоритм выбора

  1. Назовите владельца: posts, comments, post-editor.
  2. Начните плоско.
  3. Посмотрите, какие независимые сценарии реально появились.
  4. Разделите только перегруженную часть.
  5. Сохраните один понятный public API.

Когда менять структуру

Рефакторинг оправдан, если разработчику стало трудно ответить:

  • какой файл относится к списку, а какой к редактору;
  • какой store за что отвечает;
  • что разрешено импортировать снаружи.

Количество файлов само по себе не является проблемой, пока роли очевидны.