Границы доменных контекстов¶
Требования применяются к разделению прикладной модели между проектными
модулями и независимо развёртываемыми сервисами. Они не требуют
микросервисной архитектуры и не устанавливают соответствие один к одному
между доменным контекстом и сервисом. Уровни обязательности определены в
корневом README.md.
В этом документе:
- доменный контекст — именованная граница, внутри которой прикладные термины, правила и владельцы данных имеют согласованное значение;
- карта контекстов — версионируемое описание доменных контекстов и отношений между ними;
- преобразование контекста — принадлежащее границе отображение модели одного доменного контекста в контракт другого.
ARC-PAT-007. Карта доменных контекстов¶
Уровень: MUST
Применяется к: проекту с двумя и более прикладными ответственностями, разделёнными между модулями или сервисами, либо с разным смыслом одного термина
Проект должен хранить в Git карту контекстов. Для каждого доменного контекста карта должна определять стабильный идентификатор, назначение, ответственную роль, принадлежащие ему прикладные понятия, инварианты и источники истины.
Для каждого отношения между контекстами карта должна определять направление зависимости, upstream, downstream и версионируемый контракт обмена. Изменение границы, владельца или направления зависимости должно изменять карту в том же merge request.
Обоснование¶
Без явной карты одинаковые термины и данные незаметно получают нескольких владельцев, а фактические зависимости расходятся с заявленными границами.
Проверка¶
- сопоставление карты с проектными модулями, сервисами и inventory контрактов;
- поиск источника истины или межконтекстной зависимости без владельца;
- review diff карты при изменении границы либо направления зависимости.
Исключения¶
Компонент с одной прикладной ответственностью и без межконтекстного обмена MAY не иметь карты контекстов.
ARC-PAT-008. Однозначная терминология контекста¶
Уровень: MUST
Применяется к: прикладному понятию, используемому в доменном контексте и его контрактах
Внутри одного доменного контекста одно прикладное понятие должно иметь одно стабильное имя и значение в коде, схеме, контракте и нормативном описании проекта. Если одинаковый термин имеет разное значение в двух контекстах, карта контекстов должна задавать отдельные значения и явное преобразование между ними.
Отсутствующее понятие не должно подменяться пустым, нулевым или фиктивным значением понятия другого контекста.
Обоснование¶
Совпадение имени без совпадения смысла создаёт ошибки данных, которые проходят проверку физического типа.
Проверка¶
- сверка терминов карты контекстов с публичными схемами и моделями;
- contract-тест преобразования одинаково названных понятий;
- негативный тест отсутствующего и фиктивного значения.
Исключения¶
Официальное имя внешнего контракта MAY сохраняться на границе, если адаптер явно отображает его в термин доменного контекста.
ARC-PAT-009. Преобразование между доменными моделями¶
Уровень: MUST
Применяется к: обмену между доменными контекстами с различающимися моделями, терминами или правилами
Преобразование входов, результатов и ошибок должно принадлежать объявленной границе контекстов. Внутренняя модель upstream, тип хранения или framework-тип не должны становиться внутренней моделью downstream без явно опубликованного общего контракта.
Преобразование должно определять поведение для неизвестного, отсутствующего и несовместимого значения. Неуспешное преобразование не должно создавать частичный обязательный эффект downstream.
Обоснование¶
Явное преобразование не позволяет изменению внутренней модели одного контекста неявно изменить правила другого.
Проверка¶
- contract-тест всех поддерживаемых входов, результатов и классов ошибок;
- тест неизвестного, отсутствующего и несовместимого значения;
- статическая проверка отсутствия внутренних типов upstream за границей преобразования.
Исключения¶
Общий тип MAY использоваться обоими контекстами, если он сгенерирован из версионируемого опубликованного контракта, не содержит внутренней модели хранения и проверяется на совместимость.
ARC-PAT-010. Граница атомарного инварианта¶
Уровень: MUST
Применяется к: изменению состояния, для которого несколько прикладных условий должны выполняться атомарно
Все данные и решения, необходимые для атомарного инварианта, должны находиться
в одной транзакционной границе одного доменного контекста. Разделение такого
изменения между независимо отказывающими контекстами или сервисами допускается
только после замены атомарного инварианта на явно определённые промежуточные
состояния, допустимые результаты частичного отказа и восстановление по
INT-WF-001–INT-WF-007.
Выделение или объединение сервиса, меняющее эту границу, должно иметь принятый
ADR по DEV-ADR-004.
Обоснование¶
Сетевая граница не сохраняет атомарность и без новой модели состояний создаёт неопределённый бизнес-результат при частичном отказе.
Проверка¶
- сопоставление инварианта с владельцем данных и транзакционной границей;
- fault-injection между шагами разделённого изменения;
- проверка состояний, восстановления и ADR при изменении границы.
Исключения¶
Read-only объединение данных, не принимающее решение о записи или необратимом эффекте, находится вне области требования.