dzentra_bot/docs/market_intelligence/decisions/decision-003-domain-review.md

Decision 003 — Domain Review

Статус

Accepted

---

Дата принятия

Принято во время проектирования Stage-08.2 Engine Runtime Contract.

---

Контекст

После внедрения обязательного Architecture Review стало очевидно, что архитектурной проверки недостаточно.

Компонент может быть:

• технически корректным;
• соответствовать архитектуре;
• успешно компилироваться;

но при этом нарушать предметную область Market Intelligence.

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

Подобные изменения не являются архитектурными ошибками, но полностью нарушают назначение аналитического уровня платформы.

---

Проблема

Обычная архитектурная проверка отвечает на вопрос:

Правильно ли построен компонент?

Однако она не отвечает на другой вопрос:

Правильно ли компонент выполняет свою роль в предметной области?

Без отдельной проверки постепенно появляются следующие проблемы:

• аналитика начинает принимать торговые решения;
• смешиваются обязанности разных Engine;
• появляются термины с разным смыслом;
• один и тот же объект начинает означать разные вещи;
• снижается объяснимость результатов анализа.

Подобные изменения сложно обнаружить техническими средствами.

---

Рассмотренные варианты

Вариант 1

Использовать только Compile Check и Architecture Review.

Преимущества

• проще процесс разработки;
• меньше этапов проверки.

Недостатки

• отсутствует контроль предметной области;
• возможно постепенное смешивание аналитики и торговли;
• ошибки обнаруживаются слишком поздно.

---

Вариант 2

Ввести отдельный Domain Review.

После проверки архитектуры дополнительно анализируется соответствие предметной области.

Преимущества

• сохраняется чистота аналитического уровня;
• исключается смешивание ответственности;
• поддерживается единая терминология;
• повышается качество архитектурных решений;
• сохраняется объяснимость системы.

Недостатки

• увеличивается время проверки Build;
• требуется дополнительная инженерная дисциплина.

---

Принятое решение

Каждый логически завершённый Build проходит обязательный Domain Review.

Domain Review выполняется после успешного прохождения:

• Compile Check;
• Architecture Review.

---

Цель Domain Review

Domain Review проверяет не качество кода, а корректность поведения компонента относительно предметной области.

Главный вопрос проверки:

Соответствует ли данный компонент своей архитектурной роли?

---

Что проверяется

Во время Domain Review анализируются:

• корректность используемой терминологии;
• соответствие названий реальным рыночным процессам;
• отсутствие торговых решений внутри аналитических компонентов;
• отсутствие смешивания обязанностей разных Engine;
• понятность комментариев разработчику;
• соответствие Engine Runtime Contract;
• объяснимость результатов анализа;
• отсутствие скрытых смыслов и неоднозначных терминов.

---

Что не проверяется

Domain Review не оценивает:

• стиль оформления Python-кода;
• синтаксис;
• производительность реализации;
• качество алгоритмов;
• оптимизацию вычислений.

Эти вопросы относятся к другим этапам разработки.

---

Причины принятия решения

Использование Domain Review позволяет:

• сохранить чистоту предметной области;
• избежать постепенного смешивания анализа рынка и торговли;
• поддерживать единый словарь терминов;
• обеспечить объяснимость результатов;
• сохранить независимость аналитических движков.

---

Последствия

После принятия настоящего решения:

• каждый Build проходит Domain Review;
• нарушение предметной области считается архитектурным дефектом;
• аналитические компоненты остаются независимыми от торговой логики;
• новые Engine обязаны соответствовать принятой терминологии.

---

Связанные документы

• architecture_principles.md
• development_process.md
• runtime_contract.md
• reviews/domain_reviews.md

---

История изменений

Версия	Изменение
1.0	Первое принятие архитектурного решения.