serejaris Доменное моделирование
Активно строй и затачивай доменную модель проекта по ходу дизайна. Это активная дисциплина: оспаривать термины, придумывать сценарии на краях, записывать глоссарий и решения в тот момент, когда они кристаллизуются. (Просто читать CONTEXT.md за словарём это не этот скилл. Это однострочная привычка любого скилла. Этот скилл для случаев, когда ты меняешь модель, а не только потребляешь её.)
Структура файлов
В большинстве репозиториев один контекст:
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
Если в корне есть CONTEXT-MAP.md, в репозитории несколько контекстов. Карта указывает, где живёт каждый:
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← общесистемные решения
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← решения конкретного контекста
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
Создавай файлы лениво: только когда есть что писать. Если CONTEXT.md нет, создай его, когда разрешён первый термин. Если нет docs/adr/, создай его, когда понадобится первый ADR.
Во время сессии
Сверяй с глоссарием
Когда пользователь использует термин, который конфликтует с языком в CONTEXT.md, скажи сразу. "В глоссарии 'cancellation' это X, а ты, кажется, имеешь в виду Y. Что из этого верно?"
Затачивай размытый язык
Когда пользователь использует размытые или перегруженные термины, предложи точный канонический термин. "Ты говоришь 'account'. Ты имеешь в виду Customer или User? Это разные вещи."
Разбирайте конкретные сценарии
Когда обсуждаются доменные отношения, прожаривай их конкретными сценариями. Придумывай сценарии, которые бьют по краям и заставляют точно провести границы между понятиями.
Сверяй с кодом
Когда пользователь говорит, как что-то работает, проверь, согласен ли код. Если находишь противоречие, вынеси его: "Твой код отменяет Orders целиком, а ты только что сказал, что частичная отмена возможна. Что верно?"
Обновляй CONTEXT.md сразу
Когда термин разрешён, обнови CONTEXT.md тут же. Не копи их пачкой. Фиксируй по мере появления. Формат: CONTEXT-FORMAT.md.
В CONTEXT.md не должно быть деталей реализации. Не считай CONTEXT.md спецификацией, черновиком или складом реализационных решений. Это глоссарий и больше ничего.
Предлагай ADR редко
Предлагай создать ADR только когда верны все три пункта:
- Трудно откатить: цена передумать позже ощутима
- Без контекста удивляет: будущий читатель спросит "почему так сделали?"
- Результат настоящего компромисса: были реальные альтернативы, и вы выбрали одну по конкретным причинам
Если любого из трёх нет, ADR не нужен. Формат: ADR-FORMAT.md.