Работа над задачей

Ниже порядок, который помогает не проектировать лишнюю архитектуру заранее.

1. Назовите сценарий

Например: «показать список постов» или «отредактировать пост».

Плохое название: «добавить несколько файлов в data». Оно ничего не говорит о владельце.

2. Определите владельца данных

Для списка постов владелец — data/posts. Для сложного редактора с отдельным lifecycle может появиться data/post-editor.

3. Начните с минимальной структуры

Если достаточно пяти файлов, оставьте slice плоским.

4. Закройте внешнюю границу

Любые неизвестные данные сначала проходят Valibot:

const dto = parse(PostResponseSchema, input)

5. Добавьте mapper только при различии форм

Если DTO полностью совпадает с удобным типом приложения, mapper не нужен ради самого факта его существования.

Если внешний контракт использует published_at, а приложение хочет publishedAt: Date, mapper оправдан.

6. Решите, где живёт состояние

Долгоживущее бизнес-состояние → MobX store.
Состояние формы → React Hook Form.
Route params → React Router.

Не копируйте одно значение во все три места.

7. Подключите React

Smart-компонент читает store и передаёт данные dumb-компоненту.

8. Проверьте направление импортов

app → pages → components → data → shared

Если зависимость идёт в обратную сторону, пересмотрите владельца.

9. Проверьте public API

Соседний модуль должен импортировать index.ts, а не внутренний *.store.ts или *.schema.ts.

10. Проверьте lifecycle

Если store создаётся локально, должно быть понятно:

• кто его создаёт;
• сколько он живёт;
• когда сбрасывается или уничтожается.

Результат задачи

Хороший итог можно объяснить одним абзацем:

data/posts владеет постами и их внешним контрактом; MobX store хранит состояние; PostsWidget подключает store к React; PostsList только отображает props; /posts/:postId читает параметр через React Router.

Если такое объяснение получается простым, границы, скорее всего, выбраны удачно.