Files
dzentra_bot/docs/reference_model/knowledge_architecture_charter_v1.1.md

13 KiB
Raw Blame History

Dzentra Knowledge Architecture Charter

Версия: 1.1
Статус: Release
Проект: Dzentra
Подсистема: Market Intelligence


Цель

Настоящий документ определяет фундаментальные принципы разработки Knowledge Architecture проекта Dzentra.

Knowledge Architecture определяет правила построения моделей знаний, архитектурных стандартов и инженерной документации проекта Dzentra.

Все последующие архитектурные решения, документы, спецификации, Engine и программный код должны соответствовать настоящему Charter.

При возникновении противоречий настоящий документ имеет наивысший приоритет среди документов Knowledge Architecture.


1. Главная цель Dzentra

Главная задача Dzentra --- не предсказывать рынок.

Главная задача Dzentra --- максимально достоверно моделировать текущее состояние наблюдаемого рынка.

Торговое решение является следствием качества этой модели, а не целью самой модели.


2. Главная философия

Dzentra не является системой, принимающей решения на основании отдельных индикаторов.

Dzentra является системой построения модели рынка.

Переход осуществляется от подхода:

Индикатор
    ↓
Сигнал
    ↓
Сделка

к подходу:

Наблюдение
    ↓
Свойства
    ↓
Состояния
    ↓
Контекст
    ↓
Модель рынка
    ↓
Decision
    ↓
Execution

3. Архитектура платформы

Утверждённая архитектура верхнего уровня:

Market Data
        │
        ▼
Market Intelligence
        │
        ▼
Decision
        │
        ▼
Execution
        │
        ▼
Exchange

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


4. Разделение ответственности

  • Market Intelligence отвечает исключительно за построение модели наблюдаемого рынка.
  • Decision отвечает исключительно за принятие торгового решения.
  • Execution отвечает исключительно за исполнение принятого решения.

Никакой слой не должен выполнять функции другого слоя.


5. Архитектура знаний

Разработка начинается с предметной области.

Обязательная последовательность:

Предметная область
        ↓
Reference Model
        ↓
Knowledge References
        ↓
Engine Specifications
        ↓
Runtime Contracts
        ↓
Build Tasks
        ↓
Code
        ↓
Tests

Ни один этап не должен пропускаться.


6. Документация определяет код

Документация является единственным источником истины.

Код является реализацией документации.

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

Документация не изменяется ради существующей реализации.


7. Принципы построения документации

Документы Knowledge Architecture являются инженерными стандартами.

Документация должна быть:

  • нормативной;
  • однозначной;
  • самодостаточной;
  • внутренне непротиворечивой;
  • независимой от реализации.

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

Принцип читаемости

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

Текст должен быть:

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

Строгость не должна ухудшать читаемость.


8. Reference Model

Reference Model описывает исключительно предметную область.

Reference Model:

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

Reference Model отвечает на вопрос:

Что существует в предметной области и какие знания могут быть получены?


9. Принцип проектирования

Сначала определяется:

  1. что существует;
  2. какие знания можно получить;
  3. как знания связаны;
  4. какой Engine отвечает за конкретный домен;
  5. как реализовать систему.

Никогда наоборот.


10. Engine

Каждый Engine отвечает только за один домен знаний.

Engine никогда не принимает торговых решений.

Engine возвращает исключительно знания.


11. Decision

Decision объединяет результаты Engine и формирует торговое решение.


12. Execution

Execution не анализирует рынок.

Execution выполняет принятое решение.


13. Терминология

Каждый термин имеет одно официальное определение.

Использование нескольких терминов для обозначения одного понятия не допускается.


14. Принцип последовательности

Любое понятие может использовать только термины, определённые ранее.

Использование неопределённых понятий запрещается.


15. Иерархия знаний

Рынок
    ↓
Наблюдение
    ↓
Свойство
    ↓
Состояние
    ↓
Контекст
    ↓
Оценка
    ↓
Решение

Переход между уровнями является односторонним.


16. Принцип объективности

Reference Model описывает рынок независимо от наблюдателя.

Market Intelligence строит внутреннюю модель наблюдаемого рынка.


17. Независимость предметной области

Определения предметной области не должны зависеть от:

  • формата данных;
  • биржи;
  • таймфрейма;
  • языка программирования;
  • способов реализации.

18. Наблюдаемость

Любое знание должно быть основано:

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

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


19. Академическая строгость

Необходимо различать:

  • наблюдения;
  • свойства;
  • состояния;
  • контекст;
  • вероятностные оценки;
  • торговые решения.

Эти уровни не смешиваются.


20. Независимость от школ анализа

Dzentra может использовать идеи различных профессиональных подходов при условии их рациональной и наблюдаемой обоснованности.

Ни одна школа анализа не является официальной моделью Dzentra.


21. Жизненный цикл документации

Каждый документ проходит стадии:

Draft
    ↓
Review
    ↓
Release
    ↓
Evolution

22. Методология разработки документов

Сначала проектируется структура документа.

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


23. Главный принцип проекта

Документация Dzentra не описывает код. Документация Dzentra определяет код.


24. Методологический приоритет

Приоритеты Knowledge Architecture:

  1. Архитектурная целостность.
  2. Корректность модели предметной области.
  3. Масштабируемость.
  4. Простота реализации.

25. Цель Knowledge Architecture

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


26. Эволюция Charter

Настоящий Charter является конституцией Knowledge Architecture.

В него включаются только универсальные принципы, сохраняющие актуальность независимо от этапа разработки и конкретной реализации.

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