feat: add market data architecture and complete migration through build 039

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

@@ -0,0 +1,181 @@
+# 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 | Первое принятие архитектурного решения. |