# Dzentra Market Intelligence Development Process **Engineering Standard Release** --- ## Контроль документа | Свойство | Значение | |----------|-----------| | Документ | Dzentra Market Intelligence Development Process | | Тип документа | Engineering Standard | | Версия | 2.0 | | Статус | **Release** | | Подсистема | Market Intelligence | | Проект | Dzentra | | Владелец стандарта | Dzentra Architecture | | Язык | Русский | | Применяется к | Всем компонентам Market Intelligence | --- ## Оглавление ### Общие положения - Контроль документа - Статус документа - Управление стандартом - Соответствие стандарту - Нормативная терминология - Официальная терминология - Назначение - Область применения - Цель инженерного процесса - Развитие стандарта - Общие положения ### Part I. Инженерная основа - Инженерная философия - Главный принцип Dzentra - Инженерные принципы - Принцип 1. Architecture First - Принцип 2. Stable Foundation - Принцип 3. One Source of Truth - Принцип 4. Documentation Is Code - Принцип 5. Long-Term Maintainability - Принцип 6. Отсутствие предположений о существующей реализации - Принцип 7. Отсутствие преждевременных абстракций - Принцип 8. Понятная архитектура - Принцип 9. Архитектурная согласованность - Принцип 10. Непрерывность развития - Взаимосвязь инженерных принципов - Непрерывность развития архитектуры ### Part II. Процесс разработки - Общие положения - Стратегия разработки - Архитектурные уровни разработки - Полный жизненный цикл Build - Этап 1. Development Strategy - Этап 2. Architecture Design - Этап 3. Architecture Design Review - Этап 4. Architecture Approval - Этап 5. Implementation - Этап 6. Engineering Reviews - Этап 7. Documentation Update - Этап 8. User Confirmation - Этап 9. Git Commit - Этап 10. Build Closed - Definition of Done - Непрерывность разработки ### Part III. Инженерные требования - Общие инженерные требования - Требования к архитектуре - Требования к архитектурным слоям - Требования к зависимостям - Требования к компонентам - Требования к Runtime - Требования к именованию - Требования к организации файлов - Требования к публичным интерфейсам - Требования к рефакторингу - Требования к управлению техническим долгом - Непрерывность архитектурного развития ### Part IV. Инженерные проверки - Общие требования к инженерным проверкам - Принципы инженерных проверок - Архитектурные проверки - Проверки предметной области - Проверки реализации - Проверки Runtime - Проверки зависимостей - Проверки документации - Проверка готовности к выпуску - Классификация инженерных замечаний - Отчёт по инженерной проверке - Завершение системы инженерных проверок - Непрерывное совершенствование системы проверок ### Part V. Управление инженерной документацией - Назначение инженерной документации - Основные принципы управления документацией - Иерархия инженерной документации - Ответственность инженерной документации - Жизненный цикл инженерной документации - Обновление инженерной документации - Ответственность за сопровождение документации - Полнота инженерной документации - Сохранение инженерных знаний - Непрерывность сопровождения документации ### Part VI. Совместная инженерная разработка - Назначение совместной разработки - Основные принципы совместной разработки - Ответственность разработчика - Ответственность AI - Процесс принятия инженерных решений - Требования к инженерному взаимодействию - Ограничения AI - Непрерывность разработки - Качество совместной разработки - Непрерывность инженерного процесса - Развитие модели совместной разработки ### Part VII. Обеспечение качества - Назначение системы обеспечения качества - Принципы обеспечения качества - Инженерный контрольный перечень - Непрерывное совершенствование инженерного процесса - Аудит инженерного процесса - Метрики инженерного процесса - Соответствие настоящему стандарту - Сопровождение стандарта - Жизненный цикл стандарта - Заключительные положения ### Приложения - Приложение А. Глоссарий инженерных терминов - Приложение Б. Справочник статусов Build - Приложение В. Матрица Engineering Review - Приложение Г. Рекомендуемая структура проекта - Приложение Д. Шаблоны инженерной документации - Приложение Е. Каталог архитектурных диаграмм - Приложение Ж. Руководство по классификации Architecture Decision Records --- ## Статус документа Настоящий документ имеет статус **Release**. Документ является официальным инженерным стандартом подсистемы **Market Intelligence** проекта **Dzentra**. Требования настоящего стандарта являются обязательными при проектировании архитектуры, разработке компонентов, проведении инженерных проверок, сопровождении документации и дальнейшем развитии платформы. Настоящий стандарт действует до момента официального выпуска новой версии. Изменение утверждённой версии документа без выпуска новой редакции не допускается. --- ## Управление стандартом Настоящий стандарт устанавливает единый инженерный процесс разработки подсистемы **Market Intelligence**. Все архитектурные решения, изменения реализации, инженерные проверки и изменения документации должны соответствовать требованиям настоящего стандарта. Включение нового инженерного правила в настоящий стандарт допускается только при одновременном выполнении следующих условий: - правило обладает долгосрочной архитектурной ценностью; - правило подтверждено практикой разработки; - правило не противоречит действующим инженерным принципам; - правило уменьшает архитектурную сложность платформы; - правило повышает сопровождаемость, масштабируемость или согласованность архитектуры. Локальные договорённости отдельных Build не могут изменять требования настоящего стандарта. При возникновении противоречий между настоящим документом и локальными соглашениями приоритет имеет настоящий стандарт. --- ## Соответствие стандарту Компонент, Build или инженерный процесс считаются соответствующими настоящему стандарту только при выполнении всех обязательных требований, установленных данным документом. Несоблюдение хотя бы одного обязательного требования означает несоответствие настоящему стандарту. Рекомендации, приведённые в настоящем документе, не влияют на факт соответствия стандарту, однако их соблюдение считается предпочтительной инженерной практикой. Оценка соответствия выполняется в рамках Engineering Review, определённых настоящим стандартом. --- ## Нормативная терминология Во всём тексте настоящего документа используются следующие нормативные формулировки. | Формулировка | Значение | |--------------|----------| | **Должен** | Обязательное требование. Несоблюдение означает нарушение настоящего стандарта. | | **Не должен** | Действие запрещено настоящим стандартом. | | **Обязан** | Обязательное действие участника инженерного процесса. | | **Не допускается** | Полный запрет соответствующего действия. | | **Следует** | Рекомендуемая инженерная практика, допускающая обоснованные исключения. | | **Рекомендуется** | Предпочтительный способ реализации или организации процесса. | | **Может** | Допустимое действие, выполняемое по усмотрению разработчика при соблюдении остальных требований настоящего стандарта. | Если явно не указано иное, все перечисленные формулировки используются исключительно в приведённых выше значениях. --- ## Назначение Настоящий документ устанавливает единый инженерный процесс разработки подсистемы **Market Intelligence** проекта **Dzentra**. Настоящий стандарт определяет обязательные требования к: - проектированию архитектуры; - развитию платформы; - организации Build; - инженерным стандартам; - инженерным проверкам; - сопровождению документации; - совместной работе разработчика и AI; - долгосрочному развитию архитектуры. Настоящий документ является основным нормативным документом подсистемы **Market Intelligence**. Все связанные инженерные документы должны соответствовать требованиям настоящего стандарта. --- ## Область применения Настоящий стандарт распространяется на все архитектурные компоненты подсистемы **Market Intelligence**, включая: - Common Layer; - Runtime Layer; - Runtime Contract; - Engine Layer; - Coordinator Layer; - Engine Contract; - аналитические Engine; - общие архитектурные компоненты; - инженерную документацию; - Build Documentation; - Architecture Decision Record (ADR); - инженерные проверки; - полный жизненный цикл Build. Требования настоящего стандарта обязательны для: - разработчика проекта; - AI, участвующего в разработке; - всех последующих Build; - всех архитектурных компонентов платформы; - всей инженерной документации Market Intelligence. --- ## Официальная терминология В целях единообразного понимания настоящего стандарта используются следующие определения. | Термин | Определение | |---------|-------------| | **Стандарт** | Настоящий нормативный документ. | | **Build** | Минимальная логически завершённая архитектурная единица развития платформы. | | **Build Lifecycle** | Полная последовательность инженерных этапов, необходимых для завершения Build. | | **Архитектура** | Совокупность компонентов, их ответственности, границ и взаимодействий внутри платформы. | | **Архитектурный компонент** | Любая архитектурная сущность с чётко определённой областью ответственности. | | **Layer** | Архитектурный уровень платформы. | | **Runtime Contract** | Официальный контракт взаимодействия компонентов Runtime Layer. | | **Engineering Review** | Формальная инженерная проверка, предусмотренная настоящим стандартом. | | **ADR** | Architecture Decision Record — документ, фиксирующий долгосрочное архитектурное решение. | | **Платформа** | Подсистема Market Intelligence как единая архитектурная система. | | **Engineering Knowledge** | Совокупность долгосрочных инженерных знаний, сохраняемых в документации проекта. | ADR может оформляться как самостоятельный документ либо как обязательный раздел Build-документа. Для проекта Dzentra используется второй вариант. Все перечисленные термины используются в настоящем документе исключительно в приведённых выше значениях. --- ## Цель инженерного процесса Целью настоящего стандарта является обеспечение возможности многолетнего развития платформы без накопления архитектурной сложности и технического долга. Каждый завершённый Build должен способствовать: - повышению архитектурной целостности; - уменьшению сложности сопровождения; - повышению масштабируемости; - повторному использованию компонентов; - сохранению инженерных знаний; - предсказуемому развитию платформы. Основным критерием качества разработки является способность платформы становиться функционально богаче без увеличения архитектурной сложности. --- ## Развитие стандарта Настоящий Engineering Standard развивается одновременно с архитектурой платформы. Любая новая редакция настоящего документа должна: - устранять неоднозначности; - повышать инженерную согласованность; - улучшать сопровождаемость стандарта; - уменьшать сложность инженерного процесса; - сохранять совместимость с ранее принятыми архитектурными решениями. Основной принцип развития настоящего стандарта формулируется следующим образом. > **Каждая новая редакция стандарта должна делать инженерный процесс проще, понятнее и согласованнее без уменьшения полноты инженерных требований.** ## Общие положения Настоящий стандарт устанавливает единый инженерный процесс разработки подсистемы Market Intelligence проекта Dzentra. Все требования настоящего документа распространяются на полный жизненный цикл архитектурных компонентов — от проектирования до сопровождения. Настоящий стандарт регулирует: - разработку новых компонентов; - изменение существующих компонентов; - архитектурный рефакторинг; - сопровождение инженерной документации; - проведение инженерных проверок; - принятие архитектурных решений. Настоящий стандарт не описывает детали реализации отдельных алгоритмов, моделей или торговой логики. Такие требования определяются специализированными документами платформы. Настоящий документ определяет исключительно инженерные правила разработки. ## Part I. Инженерная основа Настоящая часть определяет фундаментальные инженерные принципы, на которых строится архитектура подсистемы **Market Intelligence**. Все требования, установленные последующими частями настоящего стандарта, являются развитием принципов, изложенных в данной части. Ни один инженерный процесс, архитектурное решение или реализация компонентов не должны противоречить настоящим принципам. --- ### Инженерная философия Подсистема **Market Intelligence** рассматривается как долгосрочная архитектурная платформа. Разработка платформы выполняется не ради создания отдельных файлов или реализации отдельных функций. Основной целью разработки является последовательное развитие архитектуры, способной сохранять целостность, понятность и сопровождаемость на протяжении всего жизненного цикла проекта. Исходный код рассматривается как средство реализации архитектуры, а не как самостоятельная ценность. Архитектурные решения имеют более высокий приоритет, чем особенности конкретной реализации. При возникновении противоречия между архитектурной целостностью и существующей реализацией предпочтение должно отдаваться архитектуре. --- ### Главный принцип Dzentra В основе инженерной методологии проекта лежит следующий принцип. > **Каждый новый архитектурный компонент должен уменьшать общую сложность платформы, даже если одновременно увеличивает её функциональные возможности.** Архитектурное решение считается успешным только при одновременном выполнении следующих условий: - расширяется функциональность платформы; - уменьшается сложность сопровождения; - сохраняется архитектурная целостность; - повышается возможность дальнейшего развития. Если после внедрения нового компонента архитектура становится менее понятной, принятое решение должно быть пересмотрено. --- ### Инженерные принципы Настоящий раздел определяет фундаментальные принципы, обязательные для всех последующих этапов разработки. Каждый принцип является самостоятельным нормативным требованием настоящего стандарта. --- #### Принцип 1. Architecture First Архитектура является главным инженерным активом проекта. Проектирование архитектуры должно предшествовать реализации. Ни один архитектурно значимый компонент не должен реализовываться без предварительного определения: - назначения; - области ответственности; - архитектурных границ; - зависимостей; - Runtime Contract; - места компонента в общей архитектуре. Исходный код является следствием архитектурного проектирования. Архитектура не должна формироваться под влиянием уже существующей реализации. --- #### Принцип 2. Stable Foundation Развитие платформы должно выполняться последовательно снизу вверх. Каждый следующий архитектурный уровень может использовать только полностью завершённый предыдущий уровень. ```text Architecture ↓ Common Layer ↓ Runtime Contracts ↓ Runtime Layer ↓ Engine Layer ↓ Coordinator Layer ↓ Execution Integration ↓ Presentation Layer ``` Переход к следующему архитектурному уровню допускается только после полного завершения предыдущего. Архитектурные исключения не допускаются. --- #### Принцип 3. One Source of Truth Для каждой инженерной сущности должен существовать только один официальный источник истины. Перед созданием новой архитектурной сущности необходимо определить: - существует ли эквивалентный компонент; - возможно ли повторное использование существующего решения; - требуется ли расширение существующей реализации; - действительно ли необходим новый компонент. Дублирование архитектурных компонентов не допускается. Дублирование инженерных знаний также не допускается. --- #### Принцип 4. Documentation Is Code Документация рассматривается как полноценная часть архитектуры платформы. Изменение архитектуры автоматически означает необходимость анализа и актуализации соответствующей документации. Build не может получить статус **Accepted**, пока обязательная документация не приведена в состояние, соответствующее текущей архитектуре. Документация сопровождается в соответствии с теми же инженерными требованиями, что и исходный код. --- #### Принцип 5. Long-Term Maintainability Все инженерные решения должны приниматься с учётом долгосрочного развития платформы. При выборе между несколькими допустимыми архитектурными решениями применяется следующий порядок приоритетов: 1. архитектурная целостность; 2. простота сопровождения; 3. масштабируемость; 4. повторное использование компонентов; 5. минимизация технического долга; 6. простота реализации. Краткосрочное упрощение реализации не должно ухудшать долгосрочную архитектуру. #### Принцип 6. Отсутствие предположений о существующей реализации Во время проектирования новых компонентов запрещается делать предположения о текущем состоянии проекта. При необходимости использования существующей реализации сначала должно быть выполнено изучение фактического состояния соответствующих компонентов. Источником истины является исключительно текущее состояние проекта. Предположения не являются допустимой частью инженерного процесса. Если архитектурное решение зависит от существующего исходного кода, разработчик или AI обязаны использовать только подтверждённые сведения. --- #### Принцип 7. Отсутствие преждевременных абстракций Новые архитектурные сущности создаются только при наличии подтверждённой инженерной необходимости. Создание компонентов исключительно в расчёте на возможное будущее использование не допускается. Каждая новая архитектурная сущность должна иметь практическое применение в рамках текущего Build. Если необходимость новой сущности не подтверждена архитектурой текущего Build, её реализация должна быть отложена. Преждевременное усложнение архитектуры рассматривается как источник потенциального технического долга. --- #### Принцип 8. Понятная архитектура Архитектура платформы должна быть понятной без необходимости детального анализа исходного кода. Каждый архитектурный компонент должен иметь: - очевидное назначение; - чётко определённую область ответственности; - объяснимые зависимости; - документированный публичный контракт. Архитектурное решение должно быть понятно разработчику, впервые знакомящемуся с платформой. Если понимание назначения компонента требует изучения значительного количества связанных файлов, архитектура должна быть пересмотрена. --- #### Принцип 9. Архитектурная согласованность Все архитектурные решения должны соответствовать единой инженерной модели платформы. Добавление нового компонента не должно изменять фундаментальные принципы архитектуры. При расширении платформы предпочтение отдаётся развитию существующей архитектуры посредством добавления новых компонентов, а не изменению уже сложившейся структуры. Архитектурная согласованность рассматривается как обязательное условие долгосрочного развития платформы. --- #### Принцип 10. Непрерывность развития Разработка платформы рассматривается как непрерывная последовательность завершённых Build. Каждый Build должен оставлять платформу в полностью работоспособном, архитектурно согласованном и документированном состоянии. Переход к следующему Build допускается только после завершения всех обязательных этапов текущего Build. Незавершённые архитектурные изменения не должны переноситься на последующие этапы разработки. --- ### Взаимосвязь инженерных принципов Инженерные принципы, определённые настоящей частью, образуют единую систему. Ни один принцип не должен рассматриваться изолированно. При возникновении инженерных вопросов настоящий стандарт должен применяться комплексно с учётом всех принципов одновременно. При наличии нескольких допустимых вариантов реализации предпочтение должно отдаваться решению, которое в наибольшей степени соответствует совокупности инженерных принципов, определённых настоящим стандартом. Настоящие принципы являются фундаментом всех последующих требований настоящего документа. ### Непрерывность развития архитектуры Архитектура платформы рассматривается как непрерывно развивающаяся система. Каждое инженерное решение должно приниматься с учётом уже существующей архитектуры и предполагаемого долгосрочного развития платформы. Добавление новых компонентов не должно нарушать фундаментальные архитектурные принципы, определённые настоящим стандартом. Развитие платформы должно происходить посредством последовательного расширения архитектуры, а не посредством её периодического перепроектирования. Архитектурная преемственность рассматривается как обязательное условие долгосрочной сопровождаемости платформы. Каждое новое архитектурное решение должно быть совместимо с ранее принятыми инженерными принципами либо сопровождаться официальным изменением настоящего стандарта. ## Part II. Процесс разработки Настоящая часть определяет обязательный инженерный процесс разработки компонентов подсистемы **Market Intelligence**. Если Part I определяет фундаментальные принципы архитектуры, то настоящая часть устанавливает последовательность инженерных действий, обязательных для каждого Build. Все Build проходят одинаковый жизненный цикл независимо от сложности реализации, количества изменяемых файлов или характера архитектурной задачи. Ни один этап настоящего процесса не может быть пропущен без явного архитектурного обоснования. --- ### Общие положения Единицей развития платформы является **Build**. Build представляет собой минимальную логически завершённую архитектурную единицу развития платформы. История развития проекта строится вокруг последовательности Build. Git фиксирует изменения файлов. Build фиксирует развитие архитектуры. Каждый Build должен иметь одну архитектурную цель. Границы Build определяются архитектурой, а не количеством изменяемых файлов. --- ### Стратегия разработки Разработка платформы выполняется как последовательное развитие архитектуры. Каждый новый Build должен: - решать одну архитектурную задачу; - иметь чётко определённые границы; - улучшать архитектуру платформы; - сохранять целостность существующей системы; - оставлять платформу готовой к дальнейшему развитию. Объединение нескольких независимых архитектурных задач в одном Build не допускается. Если в процессе реализации становится очевидно, что Build включает несколько самостоятельных архитектурных изменений, Build должен быть разделён. --- ### Архитектурные уровни разработки Разработка платформы выполняется последовательно снизу вверх. Каждый следующий уровень может использовать только полностью завершённый предыдущий уровень. ```text Architecture ↓ Common Layer ↓ Runtime Contracts ↓ Runtime Layer ↓ Engine Layer ↓ Coordinator Layer ↓ Execution Integration ↓ Presentation Layer ``` Нарушение указанной последовательности не допускается. --- ### Полный жизненный цикл Build Каждый Build проходит одинаковую последовательность инженерных этапов. ```text Development Strategy ↓ Architecture Design ↓ Architecture Design Review ↓ Architecture Approval ↓ Implementation ↓ Engineering Reviews ↓ Documentation Update ↓ User Confirmation ↓ Git Commit ↓ Build Closed ``` Переход к следующему этапу допускается только после успешного завершения предыдущего. Build считается завершённым только после прохождения полного жизненного цикла. --- ### Этап 1. Development Strategy Первым этапом каждого Build является определение архитектурной задачи. До начала проектирования должны быть определены: - цель Build; - ожидаемый архитектурный результат; - границы Build; - критерии завершения; - предполагаемое влияние на архитектуру платформы. На данном этапе не рассматриваются детали реализации. Основной задачей этапа является определение архитектурной цели Build. --- ### Этап 2. Architecture Design После определения архитектурной задачи выполняется проектирование решения. До начала реализации должны быть определены: - архитектурная ответственность нового компонента; - место компонента в общей архитектуре; - взаимодействие с существующими компонентами; - Runtime Contract; - необходимые модели; - события; - зависимости; - ограничения; - возможные точки расширения. Проектирование начинается с архитектуры, а не с отдельных файлов. После определения ответственности формируется структура реализации. Например: ```text Validation Layer ↓ Runtime Contract ↓ Models ↓ Events ↓ Runtime ↓ Implementation ``` Таким образом исходный код всегда является следствием архитектурного проектирования. --- ### Этап 3. Architecture Design Review После завершения проектирования выполняется обязательная архитектурная проверка. Architecture Design Review проводится до начала реализации. Цель проверки заключается в подтверждении корректности предлагаемого архитектурного решения. Architecture Design Review обязателен для: - новых Engine; - Coordinator; - Runtime; - Runtime Contract; - Engine Contract; - архитектурных моделей; - событий; - общих компонентов; - компонентов, определяющих взаимодействие между архитектурными слоями. Во время проверки оцениваются: - корректность архитектурной ответственности; - масштабируемость; - возможность повторного использования; - архитектурная согласованность; - долгосрочная сопровождаемость; - совместимость с существующей архитектурой. При необходимости архитектурное решение корректируется до начала реализации. ### Этап 4. Architecture Approval Реализация Build может начинаться только после завершения этапа **Architecture Design Review**. Архитектурное решение считается утверждённым, если одновременно выполнены следующие условия: - определена область ответственности компонента; - определены архитектурные границы; - определены зависимости; - определён Runtime Contract (если применимо); - отсутствуют архитектурные противоречия; - подтверждена возможность дальнейшего масштабирования; - подтверждено соответствие инженерным принципам настоящего стандарта. После утверждения архитектуры допускается переход к реализации. Изменение утверждённой архитектуры в процессе реализации допускается только после повторного архитектурного анализа и повторного Architecture Design Review. --- ### Этап 5. Implementation Этап Implementation представляет собой реализацию ранее утверждённого архитектурного решения. Во время реализации запрещается: - изменять архитектурную ответственность компонентов; - нарушать границы архитектурных слоёв; - добавлять необоснованные зависимости; - создавать временные инженерные решения; - вводить преждевременные абстракции; - изменять Runtime Contract без архитектурного анализа. Каждый компонент должен реализовывать исключительно собственную область ответственности. Любая дополнительная ответственность рассматривается как потенциальное нарушение архитектурной целостности платформы. Если в процессе реализации возникает необходимость изменения архитектуры, реализация должна быть приостановлена до проведения соответствующего архитектурного анализа. --- ### Этап 6. Engineering Reviews После завершения реализации выполняется обязательный комплекс инженерных проверок. Engineering Reviews подтверждают соответствие результата требованиям настоящего стандарта. Минимальный обязательный перечень включает: - Architecture Review; - Domain Review; - Code Review; - Documentation Review. При необходимости дополнительно выполняются: - Runtime Review; - Dependency Review; - Release Review. Каждый Review оценивает только собственную область ответственности. Результаты одного Review не заменяют проведение других обязательных проверок. При наличии критических замечаний реализация должна быть доработана до перехода к следующему этапу. --- ### Этап 7. Documentation Update После успешного завершения инженерных проверок выполняется актуализация документации. Во время данного этапа определяется: - какие документы требуют изменения; - необходимо ли создание новых документов; - какие инженерные знания должны быть сохранены; - требуется ли обновление Architecture Decision Record; - требуется ли изменение Runtime Contract; - требуется ли обновление настоящего стандарта. Документация обновляется одновременно с архитектурой. Отложенное обновление документации не допускается. --- ### Этап 8. User Confirmation После завершения инженерных проверок и обновления документации Build представляется разработчику для утверждения. Разработчик подтверждает: - достижение архитектурной цели; - завершённость реализации; - соответствие инженерным требованиям; - готовность Build к закрытию. До получения подтверждения Build считается открытым. --- ### Этап 9. Git Commit После утверждения Build рекомендуется выполнить отдельный Git Commit. Каждый Commit должен соответствовать одному логически завершённому Build. Объединение нескольких независимых Build в одном Commit не рекомендуется. Разделение одного Build на несколько Commit допускается только при наличии инженерного обоснования. Git Commit рассматривается как фиксация завершённого этапа развития архитектуры. --- ### Этап 10. Build Closed После выполнения всех требований настоящего стандарта Build получает статус **Accepted**. Закрытый Build должен удовлетворять следующим условиям: - архитектура утверждена; - реализация завершена; - обязательные Engineering Review успешно выполнены; - документация актуализирована; - инженерные знания сохранены; - разработчик подтвердил завершение Build. Только после получения статуса **Accepted** допускается переход к следующему Build. Незавершённые архитектурные изменения не должны переноситься на последующие Build. --- ### Definition of Done Build считается завершённым только при одновременном выполнении всех требований настоящего стандарта. Definition of Done является обязательным критерием завершения любого Build. Build не может получить статус **Accepted**, пока хотя бы одно обязательное требование остаётся невыполненным. Definition of Done включает следующие обязательные критерии: 1. Architecture Completed. 2. Implementation Completed. 3. Engineering Reviews Passed. 4. Documentation Updated. 5. User Confirmation Received. 6. Git Commit Completed. 7. Build Closed. Подробные требования к каждому критерию определяются настоящим стандартом. --- #### Architecture Completed Архитектура считается завершённой, если: - определено назначение компонента; - определена область ответственности; - определены архитектурные границы; - определены зависимости; - определён Runtime Contract (если применимо); - определены ограничения; - определено место компонента в архитектуре платформы. --- #### Implementation Completed Реализация считается завершённой, если: - полностью соответствует утверждённой архитектуре; - отсутствуют временные решения; - отсутствуют незавершённые участки; - отсутствуют известные нарушения настоящего стандарта; - отсутствуют архитектурные компромиссы, перенесённые на будущие Build. --- #### Engineering Reviews Passed Все обязательные Engineering Review должны быть успешно завершены. Наличие критических замечаний исключает возможность получения Build статуса **Accepted**. --- #### Documentation Updated Вся инженерная документация должна соответствовать текущему состоянию архитектуры. Обновлению подлежат только документы, затронутые текущим Build. --- #### User Confirmation Received Разработчик подтвердил завершение Build и отсутствие незавершённых архитектурных задач. --- #### Git Commit Completed Изменения Build зафиксированы в системе контроля версий в соответствии с инженерной практикой проекта. --- #### Build Closed Все обязательные требования настоящего стандарта выполнены. Build получил статус **Accepted** и считается завершённым. ### Непрерывность разработки Разработка платформы рассматривается как непрерывная последовательность полностью завершённых Build. Новый Build не должен начинаться до получения текущим Build статуса **Accepted**, за исключением случаев, когда иное явно предусмотрено утверждённым планом разработки. Каждый Build обязан оставлять платформу в состоянии, пригодном для дальнейшего развития. После завершения Build должны одновременно сохраняться: - архитектурная целостность платформы; - работоспособность реализации; - актуальность инженерной документации; - полнота инженерных знаний; - возможность безопасного начала следующего Build. Незавершённые архитектурные изменения не должны переноситься на последующие этапы разработки. История развития платформы рассматривается как непрерывная последовательность завершённых Build, каждый из которых представляет самостоятельный этап эволюции архитектуры. Именно последовательность завершённых Build образует официальную историю развития архитектуры платформы Dzentra. По этой причине каждый Build рассматривается как самостоятельная архитектурная единица, а не как совокупность изменений исходного кода. ## Part III. Инженерные требования Настоящая часть устанавливает обязательные инженерные требования, которым должны соответствовать все архитектурные компоненты подсистемы **Market Intelligence**. Если Part II определяет процесс разработки, то настоящая часть определяет требования к результату разработки. Все архитектурные компоненты платформы должны соответствовать требованиям настоящего стандарта независимо от времени их создания, способа реализации или используемых технологий. Настоящие требования обязательны для: - разработки новых компонентов; - модификации существующих компонентов; - архитектурного рефакторинга; - проектирования новых Engine; - развития Runtime; - разработки Coordinator; - развития общей архитектуры платформы. Несоответствие настоящим требованиям рассматривается как нарушение инженерного стандарта. --- ### Общие инженерные требования Все архитектурные компоненты платформы должны удовлетворять следующим обязательным требованиям. Каждый компонент обязан: - иметь единственную область ответственности; - иметь определённые архитектурные границы; - использовать только допустимые архитектурные зависимости; - взаимодействовать через официальные архитектурные контракты; - соответствовать инженерным принципам настоящего стандарта; - быть пригодным для долгосрочного сопровождения. Архитектурные требования распространяются как на новые компоненты, так и на результаты рефакторинга существующих компонентов. При возникновении противоречий между особенностями реализации и требованиями настоящего стандарта приоритет имеют требования настоящего стандарта. --- ### Требования к архитектуре Архитектура является главным инженерным активом платформы. Каждый новый архитектурный компонент должен повышать качество общей архитектуры. Во время проектирования любого компонента должны быть определены: - область ответственности; - архитектурные границы; - зависимости; - точки расширения; - ограничения; - ожидаемое развитие компонента. Каждый компонент должен иметь одну основную архитектурную ответственность. Объединение нескольких независимых обязанностей в одном компоненте не допускается. Архитектура должна оставаться понятной без необходимости анализа реализации. --- #### Архитектурная ответственность Каждый архитектурный компонент отвечает только за одну область ответственности. Если компонент начинает выполнять несколько независимых функций, он подлежит архитектурному разделению. Архитектурная ответственность должна быть очевидной из: - назначения компонента; - структуры каталогов; - публичного интерфейса; - инженерной документации. Архитектурная ответственность не должна зависеть от особенностей реализации. --- #### Архитектурная простота При наличии нескольких допустимых архитектурных решений предпочтение должно отдаваться наиболее простому. Под архитектурной простотой понимаются: - минимальное количество зависимостей; - минимальное количество уровней взаимодействия; - отсутствие скрытого поведения; - отсутствие неявных контрактов; - высокая читаемость архитектуры; - объяснимость архитектурных решений. Простота является обязательным инженерным требованием. Искусственное усложнение архитектуры не допускается. --- #### Развитие архитектуры Архитектура должна поддерживать непрерывное развитие платформы. Добавление нового Engine, Runtime, Coordinator или другого архитектурного компонента не должно требовать изменения фундаментальной структуры платформы. Развитие архитектуры должно происходить посредством добавления новых компонентов, а не посредством изменения уже существующей архитектуры. Каждое архитектурное решение должно учитывать возможность дальнейшего расширения платформы без нарушения её архитектурной целостности. --- ### Требования к архитектурным слоям Архитектура платформы строится как последовательность независимых архитектурных слоёв. Каждый слой имеет собственную область ответственности. Архитектурные границы между слоями являются обязательными. Взаимодействие между слоями допускается только посредством официально определённых архитектурных контрактов. Нарушение границ архитектурных слоёв рассматривается как нарушение настоящего стандарта. --- #### Иерархия слоёв Архитектура платформы строится в следующей последовательности. ```text Architecture ↓ Common Layer ↓ Runtime Contracts ↓ Runtime Layer ↓ Engine Layer ↓ Coordinator Layer ↓ Execution Integration ↓ Presentation Layer ``` Каждый слой может использовать только полностью завершённый предыдущий слой. Нарушение указанной последовательности не допускается. --- #### Независимость слоёв Каждый архитектурный слой должен быть максимально независимым. Слой не должен зависеть от внутренней реализации других слоёв. Взаимодействие между слоями осуществляется исключительно посредством официальных архитектурных контрактов. Наличие прямых зависимостей от внутренней реализации другого слоя не допускается. --- #### Изоляция слоёв Внутренняя реализация архитектурного слоя является закрытой. Другие слои не должны использовать внутренние структуры соседнего слоя. Любое взаимодействие должно осуществляться только через публичный контракт соответствующего слоя. Изоляция слоёв является обязательным условием сопровождаемости архитектуры. --- #### Стабильность слоёв Архитектурные слои обладают различной степенью изменяемости. Наиболее стабильными являются: - Common Layer; - Runtime Contract; - Runtime Models. Наиболее изменяемыми являются: - Engine; - Coordinator; - пользовательские сценарии. При проектировании архитектуры необходимо стремиться к минимизации изменений наиболее стабильных слоёв. ### Требования к зависимостям Архитектурные зависимости являются частью архитектуры платформы. Каждая зависимость должна иметь инженерное обоснование и соответствовать архитектурным принципам настоящего стандарта. Добавление новой зависимости рассматривается как архитектурное изменение и должно оцениваться с точки зрения её влияния на сопровождаемость, масштабируемость и целостность платформы. Использование зависимости без подтверждённой инженерной необходимости не допускается. --- #### Направление зависимостей Все архитектурные зависимости должны быть однонаправленными. Направление зависимостей определяется архитектурной иерархией платформы. ```text Presentation Layer ↓ Coordinator Layer ↓ Engine Layer ↓ Runtime Layer ↓ Common Layer ``` Нижележащий слой не должен зависеть от вышележащего слоя. Нарушение установленного направления зависимостей рассматривается как нарушение архитектурной целостности платформы. --- #### Циклические зависимости Циклические зависимости запрещаются. При обнаружении циклической зависимости архитектура должна быть переработана до её полного устранения. Использование дополнительных абстракций исключительно для сокрытия циклической зависимости не допускается. Любая циклическая зависимость рассматривается как архитектурный дефект. --- #### Скрытые зависимости Все архитектурные зависимости должны быть явными. Компонент не должен иметь скрытых требований к внутренней реализации другого компонента. Поведение архитектурного компонента должно быть полностью объяснимо на основании его публичного интерфейса и официальных контрактов. Наличие скрытых зависимостей ухудшает сопровождаемость платформы и не соответствует требованиям настоящего стандарта. --- ### Требования к компонентам Каждый компонент платформы рассматривается как самостоятельная архитектурная единица. Компонент обязан иметь: - единственную область ответственности; - официальный публичный контракт; - понятный жизненный цикл; - определённые архитектурные границы; - инженерную документацию, соответствующую его назначению. Компонент не должен выполнять функции, относящиеся к ответственности других архитектурных компонентов. --- #### Ответственность компонентов Каждый компонент должен реализовывать только одну инженерную задачу. Если компонент начинает выполнять несколько независимых функций, он подлежит архитектурному разделению. Дополнительная ответственность рассматривается как признак нарушения принципа единственной ответственности. --- #### Жизненный цикл компонентов Архитектурные компоненты должны иметь явно определённый жизненный цикл. При проектировании нового компонента должны быть определены: - владелец жизненного цикла; - момент создания компонента; - момент завершения жизненного цикла; - допустимость повторного использования экземпляров; - требования к сохранению внутреннего состояния. Если компонент создаётся Runtime, жизненный цикл экземпляра должен полностью определяться Runtime. Компонент не должен самостоятельно управлять собственным жизненным циклом. Если архитектурная модель предполагает создание нового экземпляра при каждом выполнении, повторное использование экземпляров не допускается. Правила жизненного цикла компонента должны быть отражены в соответствующем архитектурном контракте. --- #### Контракты компонентов Взаимодействие компонентов допускается только через официальные архитектурные контракты. Использование внутренних структур другого компонента запрещается. Изменение публичного контракта рассматривается как архитектурное изменение и требует оценки его влияния на существующую архитектуру. --- #### Повторное использование компонентов Перед созданием нового компонента должна быть выполнена оценка возможности повторного использования существующего решения. При наличии архитектурно эквивалентного компонента предпочтение должно отдаваться его расширению или повторному использованию. Создание новой реализации при наличии подходящего существующего компонента требует инженерного обоснования. --- ### Требования к Runtime Runtime представляет собой самостоятельную архитектурную подсистему платформы. Runtime отвечает исключительно за описание состояния системы и официальные контракты взаимодействия. Runtime не должен содержать аналитическую, торговую или координирующую логику. Ответственность Runtime ограничивается представлением состояния платформы и поддержкой взаимодействия между архитектурными компонентами. --- #### Ответственность Runtime Runtime должен определять: - модели состояния; - Runtime Contract; - Runtime Events; - жизненный цикл Runtime; - правила представления состояния. Runtime не должен принимать инженерные, аналитические или торговые решения. Любая подобная логика должна располагаться за пределами Runtime Layer. --- #### Runtime Contract Runtime Contract является официальным архитектурным контрактом платформы. Любое изменение Runtime Contract требует: - проведения Architecture Design Review; - анализа совместимости; - оценки влияния на существующие Engine; - обновления инженерной документации. Изменение Runtime Contract без архитектурного анализа не допускается. --- #### Стабильность Runtime Runtime относится к наиболее стабильным архитектурным компонентам платформы. Изменение Runtime допускается только при наличии подтверждённой архитектурной необходимости. При проектировании новых компонентов предпочтение должно отдаваться решениям, не требующим изменения существующего Runtime. Минимизация изменений Runtime рассматривается как один из факторов долгосрочной стабильности архитектуры. ### Требования к именованию Именование архитектурных компонентов является частью архитектуры платформы. Название каждого компонента должно однозначно отражать его область ответственности и назначение. Использование неоднозначных, временных или вводящих в заблуждение названий не допускается. Единообразное именование облегчает понимание архитектуры, снижает вероятность ошибок и способствует долгосрочной сопровождаемости платформы. --- #### Наименование компонентов Название архитектурного компонента должно: - отражать его основную ответственность; - быть однозначным; - быть кратким; - соответствовать принятой терминологии платформы. Название не должно описывать детали реализации. --- #### Наименование файлов Имя файла должно отражать назначение содержащегося в нём компонента. Не допускается использование: - временных названий; - неопределённых сокращений; - имён, не отражающих архитектурную ответственность. Структура имён файлов должна быть единообразной во всей платформе. --- #### Единообразие терминологии Каждый инженерный термин должен иметь только одно официальное определение. Использование различных названий для одной и той же архитектурной сущности не допускается. Общие инженерные термины фиксируются в Glossary и используются во всей документации в неизменном виде. --- ### Требования к организации файлов Организация исходного кода должна отражать архитектуру платформы. Структура каталогов и файлов должна облегчать понимание системы и не должна зависеть от особенностей реализации. --- #### Структура пакетов Каждый каталог представляет самостоятельную архитектурную область. Организация каталогов должна определяться архитектурной ответственностью компонентов, а не типом размещаемых файлов. Структура проекта должна быть последовательной и единообразной. --- #### Размер компонентов Каждый файл должен содержать только логически связанную функциональность. Если понимание содержимого файла становится затруднительным, должна быть выполнена оценка необходимости его разделения. Разделение выполняется по архитектурной ответственности, а не по количеству строк исходного кода. --- #### Независимость модулей Модули должны быть максимально независимыми друг от друга. Изменение одного модуля не должно приводить к необходимости массового изменения соседних модулей. Минимизация связанности рассматривается как обязательное архитектурное требование. --- ### Требования к публичным интерфейсам Публичный интерфейс является официальным архитектурным контрактом компонента. Проектирование публичного интерфейса должно выполняться с той же тщательностью, что и проектирование архитектуры самого компонента. --- #### Публичный интерфейс Публичный интерфейс должен быть: - минимальным; - стабильным; - понятным; - документированным; - достаточным для выполнения задач компонента. Добавление новых публичных элементов должно иметь архитектурное обоснование. --- #### Внутренняя реализация Внутренняя реализация не является частью публичного контракта. Изменение внутренней реализации допускается при условии сохранения поведения публичного интерфейса. Другие компоненты не должны зависеть от внутренних особенностей реализации. --- ### Требования к рефакторингу Рефакторинг является обязательной частью жизненного цикла платформы. Цель рефакторинга заключается в улучшении архитектуры без изменения внешнего поведения системы. Рефакторинг должен повышать читаемость, сопровождаемость и архитектурную согласованность платформы. --- #### Общие требования Во время рефакторинга не допускается: - изменение внешнего поведения компонентов; - нарушение архитектурных границ; - объединение независимых областей ответственности; - создание временных инженерных решений. Каждый рефакторинг должен улучшать архитектуру платформы. --- #### Инкрементальный рефакторинг Рефакторинг должен выполняться небольшими логически завершёнными этапами. Каждый этап рекомендуется оформлять как самостоятельный Build. По завершении каждого этапа платформа должна оставаться работоспособной, документированной и соответствующей настоящему стандарту. --- ### Требования к управлению техническим долгом Технический долг рассматривается как исключительная ситуация. Накопление технического долга не является допустимой стратегией развития платформы. Каждое временное инженерное решение должно иметь документированное обоснование и план устранения. --- #### Допустимый технический долг Временное инженерное решение допускается только при одновременном выполнении следующих условий: - существует объективная причина его применения; - ограничение документировано; - определён способ устранения; - решение не нарушает архитектурные принципы настоящего стандарта. Допустимый технический долг должен устраняться при первой практической возможности. --- #### Архитектурный долг Архитектурный долг не допускается. Если архитектурное решение ухудшает сопровождаемость, масштабируемость или целостность платформы, оно должно быть пересмотрено до завершения Build. Архитектурные компромиссы не должны переноситься на последующие Build. --- ### Непрерывность архитектурного развития Архитектура платформы рассматривается как непрерывно развивающаяся система. Каждое новое архитектурное решение должно быть совместимо с фундаментальными инженерными принципами настоящего стандарта. Развитие платформы должно происходить посредством последовательного расширения архитектуры, а не посредством её периодического перепроектирования. Добавление новых компонентов не должно нарушать существующую архитектурную целостность платформы. Каждый завершённый Build должен делать архитектуру: - более понятной; - более согласованной; - более масштабируемой; - более пригодной для долгосрочного сопровождения. Непрерывное архитектурное развитие рассматривается как обязательное условие инженерной зрелости платформы. ## Part IV. Инженерные проверки Настоящая часть устанавливает единую систему инженерных проверок, применяемую ко всем Build подсистемы **Market Intelligence**. Инженерные проверки являются обязательной частью жизненного цикла каждого Build. Их целью является подтверждение того, что результаты разработки соответствуют требованиям настоящего стандарта. Инженерные проверки оценивают архитектуру, реализацию, инженерную документацию и соблюдение установленного процесса разработки. Build не может получить статус **Accepted** до успешного завершения всех обязательных проверок. --- ### Общие требования к инженерным проверкам Каждый Build обязан пройти полный перечень инженерных проверок, предусмотренных настоящим стандартом. Каждая проверка представляет собой самостоятельную инженерную процедуру и имеет собственную область ответственности. Результаты одной проверки не заменяют проведение других обязательных проверок. Все инженерные проверки выполняются независимо от объёма реализации, количества изменённых файлов или сложности архитектурной задачи. --- ### Принципы инженерных проверок Система Engineering Review строится на следующих фундаментальных принципах. --- #### Независимость Каждая инженерная проверка оценивает только собственную область ответственности. Архитектурные вопросы рассматриваются исключительно в рамках Architecture Review. Предметная область оценивается исключительно в рамках Domain Review. Качество реализации оценивается исключительно в рамках Code Review. Документация оценивается исключительно в рамках Documentation Review. Смешивание различных видов инженерной оценки не допускается. --- #### Объективность Все выводы инженерных проверок должны основываться исключительно на требованиях настоящего стандарта. Личные предпочтения участников разработки не являются основанием для замечаний. Каждое замечание должно иметь инженерное обоснование. --- #### Прослеживаемость Каждое замечание должно быть: - воспроизводимым; - проверяемым; - связанным с конкретным требованием настоящего стандарта; - сопровождаемым инженерным обоснованием. Замечания, не имеющие связи с требованиями настоящего стандарта, не рассматриваются как официальные результаты Engineering Review. --- #### Направленность на улучшение Основной целью Engineering Review является повышение качества платформы. Инженерные проверки не рассматриваются как формальная процедура контроля. Каждая проверка должна способствовать: - улучшению архитектуры; - повышению сопровождаемости; - уменьшению технического долга; - сохранению инженерной согласованности платформы. --- ### Архитектурные проверки Архитектурные проверки подтверждают соответствие архитектуры требованиям настоящего стандарта. Архитектурные проверки проводятся как до начала реализации, так и после её завершения. Система архитектурных проверок включает: - Architecture Design Review; - Architecture Review. Каждая из указанных проверок имеет самостоятельную область ответственности. --- #### Architecture Design Review Architecture Design Review выполняется до начала реализации. Цель проверки заключается в подтверждении корректности предлагаемого архитектурного решения. Architecture Design Review обязателен для: - новых Engine; - Coordinator; - Runtime; - Runtime Contract; - Engine Contract; - архитектурных моделей; - событий; - компонентов, определяющих взаимодействие архитектурных слоёв. Во время проверки оцениваются: - архитектурная ответственность; - архитектурные границы; - масштабируемость; - возможность повторного использования; - долгосрочная сопровождаемость; - соответствие инженерным принципам настоящего стандарта. При отрицательном результате реализация Build не допускается. --- #### Architecture Review Architecture Review проводится после завершения реализации. Цель проверки заключается в подтверждении соответствия реализованной архитектуры требованиям настоящего стандарта. Во время проверки оцениваются: - соблюдение архитектурных требований; - соблюдение требований к слоям; - соблюдение требований к зависимостям; - соблюдение требований к Runtime; - соблюдение требований к компонентам; - соответствие утверждённой архитектуре. Architecture Review оценивает исключительно архитектуру платформы и не рассматривает вопросы предметной области или качества реализации. ### Проверки предметной области Проверки предметной области подтверждают соответствие реализованных компонентов требованиям предметной области **Market Intelligence**. Данные проверки не оценивают качество архитектуры или реализации. Их задачей является подтверждение корректности моделирования предметной области. --- #### Domain Review Domain Review проводится после завершения реализации Build. Цель проверки заключается в подтверждении того, что реализованные компоненты корректно отражают предметную область платформы. Во время проверки оцениваются: - корректность терминологии; - соответствие моделей предметной области; - отсутствие смешивания аналитической и торговой логики; - объяснимость поведения компонентов; - согласованность используемых понятий; - соответствие принятой терминологии платформы. Domain Review не рассматривает вопросы архитектуры или качества реализации. Архитектурные замечания рассматриваются исключительно в рамках Architecture Review. --- ### Проверки реализации Проверки реализации подтверждают качество инженерной реализации компонентов платформы. Основной задачей данных проверок является обеспечение простоты сопровождения, читаемости и соответствия инженерным требованиям настоящего стандарта. --- #### Code Review Code Review проводится после завершения реализации Build. Цель проверки заключается в подтверждении качества инженерной реализации. Во время проверки оцениваются: - читаемость исходного кода; - простота реализации; - отсутствие избыточной сложности; - отсутствие дублирования; - отсутствие временных инженерных решений; - соблюдение требований к именованию; - соблюдение требований к организации файлов; - возможность повторного использования существующих компонентов. Code Review оценивает исключительно качество реализации. Архитектурные вопросы рассматриваются только в рамках Architecture Review. --- #### Общие требования к реализации При выполнении Code Review подтверждается соблюдение следующих требований: - каждая сущность имеет единственную ответственность; - отсутствует необоснованное дублирование; - отсутствуют скрытые зависимости; - отсутствуют преждевременные абстракции; - реализация соответствует утверждённой архитектуре. При выявлении нарушений формируются инженерные замечания в соответствии с настоящим стандартом. --- ### Проверки Runtime Проверки Runtime применяются исключительно к компонентам Runtime Layer. Они подтверждают корректность реализации архитектурных контрактов Runtime и совместимость компонентов между собой. --- #### Runtime Review Runtime Review проводится при изменении компонентов Runtime. Во время проверки оцениваются: - корректность Runtime Contract; - стабильность Runtime Models; - корректность Runtime Events; - совместимость Runtime; - жизненный цикл Runtime; - влияние изменений на существующие Engine. Runtime Review не проводится для компонентов, не относящихся к Runtime Layer. --- ### Проверки зависимостей Проверки зависимостей подтверждают соответствие архитектурных зависимостей требованиям настоящего стандарта. Каждая новая зависимость рассматривается как самостоятельное архитектурное изменение. --- #### Dependency Review Dependency Review проводится при появлении новых архитектурных зависимостей либо при изменении существующих. Во время проверки оцениваются: - направление зависимостей; - отсутствие циклических зависимостей; - отсутствие скрытых зависимостей; - необходимость каждой новой зависимости; - соответствие требованиям к архитектурным слоям. При обнаружении нарушений архитектура должна быть пересмотрена до завершения Build. ### Проверки документации Проверки документации подтверждают соответствие инженерной документации текущему состоянию платформы. Документация рассматривается как часть архитектуры и подлежит обязательной проверке после завершения каждого Build. --- #### Documentation Review Documentation Review проводится после завершения реализации и выполнения остальных инженерных проверок. Цель проверки заключается в подтверждении того, что инженерная документация полностью соответствует реализованным архитектурным изменениям. Во время проверки оцениваются: - полнота документации; - актуальность документов; - отсутствие противоречий; - соответствие документации текущему состоянию платформы; - необходимость создания новых документов; - необходимость обновления существующих документов. Documentation Review является обязательной частью жизненного цикла каждого Build. Build не может получить статус **Accepted** до успешного завершения Documentation Review. --- #### Полнота документации Документация считается полной, если одновременно выполняются следующие условия: - описаны все архитектурные изменения; - обновлены все обязательные документы; - отсутствуют внутренние противоречия; - документация соответствует текущему состоянию платформы; - долгосрочные инженерные решения зафиксированы в соответствующих документах. Неполная документация рассматривается как незавершённый Build. --- ### Проверка готовности к выпуску После успешного завершения всех обязательных инженерных проверок выполняется итоговая проверка готовности Build к выпуску. --- #### Release Review Release Review является заключительной инженерной проверкой Build. Цель проверки заключается в подтверждении завершённости инженерного процесса. Во время Release Review подтверждается: - выполнение Definition of Done; - успешное завершение обязательных инженерных проверок; - отсутствие открытых критических замечаний; - актуальность инженерной документации; - готовность Build к интеграции в основную ветвь разработки. Release Review не заменяет другие виды инженерных проверок. Он подтверждает исключительно завершённость процесса разработки. --- ### Классификация инженерных замечаний Все замечания, сформированные в ходе Engineering Review, классифицируются по степени их влияния на качество платформы. Единая классификация обеспечивает одинаковую интерпретацию результатов инженерных проверок независимо от вида Review. --- #### Critical Критическое замечание означает нарушение обязательных требований настоящего стандарта. При наличии хотя бы одного критического замечания Build не может получить статус **Accepted**. --- #### Major Существенное замечание указывает на нарушение инженерных требований, которое должно быть устранено до завершения Build. --- #### Minor Незначительное замечание относится к вопросам читаемости, единообразия оформления или сопровождаемости. Такие замечания рекомендуется устранить, однако они не препятствуют завершению Build. --- #### Recommendation Рекомендация не является замечанием. Она содержит предложение по дальнейшему улучшению архитектуры, реализации или документации и может быть учтена в одном из последующих Build. --- ### Отчёт по инженерной проверке Результатом каждой инженерной проверки является официальный инженерный отчёт. Engineering Review Report должен содержать: - вид проверки; - область проверки; - перечень выявленных замечаний; - рекомендации; - итоговое решение. Отчёт становится частью инженерной истории соответствующего Build и обеспечивает прослеживаемость принятых решений. --- ### Завершение системы инженерных проверок Все обязательные инженерные проверки должны быть успешно завершены до закрытия Build. Общая последовательность выполнения проверок выглядит следующим образом. ```text Architecture Design Review ↓ Architecture Review ↓ Domain Review ↓ Code Review ↓ Runtime Review (при необходимости) ↓ Dependency Review (при необходимости) ↓ Documentation Review ↓ Release Review ``` Каждая проверка подтверждает только собственную область ответственности. Только после успешного завершения всех обязательных инженерных проверок Build может получить статус **Accepted**. --- ### Непрерывное совершенствование системы проверок Система Engineering Review рассматривается как развивающаяся часть инженерного процесса. При появлении новых архитектурных требований допускается расширение перечня инженерных проверок при условии соблюдения следующих принципов: - каждая новая проверка должна иметь самостоятельную область ответственности; - новая проверка не должна дублировать существующие проверки; - необходимость новой проверки должна быть подтверждена практикой разработки; - изменения должны быть отражены в настоящем стандарте. Развитие системы инженерных проверок должно повышать качество платформы без увеличения сложности инженерного процесса. ## Part V. Управление инженерной документацией Настоящая часть устанавливает единые требования к управлению инженерной документацией подсистемы **Market Intelligence**. Инженерная документация рассматривается как неотъемлемая часть архитектуры платформы и развивается одновременно с исходным кодом. Каждый Build обязан сопровождаться актуализацией инженерной документации в объёме, соответствующем выполненным архитектурным изменениям. Изменение архитектуры без соответствующего изменения документации считается незавершённой инженерной работой. --- ### Назначение инженерной документации Основной целью инженерной документации является сохранение инженерных знаний платформы. Документация должна обеспечивать возможность: - понимания архитектуры платформы; - восстановления причин принятых архитектурных решений; - безопасного продолжения разработки после длительного перерыва; - подключения нового разработчика к проекту; - перехода между Build без потери архитектурного контекста; - продолжения разработки в новом AI-чате. Документация должна объяснять архитектуру платформы, а не дублировать исходный код. --- ### Основные принципы управления документацией Система инженерной документации строится на следующих принципах. --- #### Документация является частью архитектуры Инженерная документация рассматривается как архитектурный актив платформы. Изменение архитектуры автоматически требует анализа необходимости обновления соответствующей документации. --- #### Документация развивается одновременно с платформой Каждый Build изменяет не только исходный код, но и инженерные знания проекта. Документация сопровождает развитие архитектуры на протяжении всего жизненного цикла платформы. --- #### Прослеживаемость инженерных решений Каждое долгосрочное архитектурное решение должно иметь документированное объяснение. Документация должна позволять определить: - причину принятия решения; - момент его появления; - последствия применения; - документ, которым данное решение регулируется. --- #### Сопровождаемость документации Структура инженерной документации должна оставаться простой и понятной. Если изменение одного архитектурного компонента требует обновления большого количества документов, структура документации подлежит пересмотру. Сложность сопровождения документации должна уменьшаться одновременно со сложностью архитектуры. --- ### Иерархия инженерной документации Инженерная документация организуется как единая иерархическая система. Каждый документ имеет собственную область ответственности. Дублирование инженерной информации между документами не допускается. Общая структура документации имеет следующий вид. ```text README ↓ Development Process ↓ Architecture Principles ↓ Runtime Contracts ↓ Architecture Decision Records ↓ Build Documentation ↓ Engineering Reviews ↓ Diagrams ↓ Glossary ``` Каждый уровень документации отвечает исключительно за собственную область инженерных знаний. ### Ответственность инженерной документации Каждый документ инженерной документации имеет единственную область ответственности. Пересечение областей ответственности между документами не допускается. Если одно инженерное правило уже подробно описано в соответствующем документе, остальные документы должны ссылаться на него, а не повторять его содержание. --- #### README README предоставляет общее описание подсистемы. README содержит обзор архитектуры, назначения подсистемы и ссылки на основную инженерную документацию. README не используется для описания инженерных стандартов или архитектурных правил. --- #### Development Process Development Process определяет официальный инженерный процесс разработки. Настоящий документ является основным инженерным стандартом подсистемы Market Intelligence. Все остальные инженерные документы должны соответствовать требованиям настоящего стандарта. --- #### Architecture Principles Документ Architecture Principles определяет фундаментальные архитектурные принципы платформы. Изменение данного документа допускается только при изменении долгосрочных архитектурных принципов. --- #### Runtime Contracts Документы Runtime Contracts определяют официальные контракты взаимодействия компонентов Runtime Layer. Изменение Runtime Contract рассматривается как архитектурное изменение и требует прохождения установленного инженерного процесса. --- #### Architecture Decision Records Architecture Decision Record используется для фиксации долгосрочных архитектурных решений. ADR должен объяснять: - рассматриваемую проблему; - принятое решение; - причины принятия решения; - последствия данного решения; - рассмотренные альтернативы. Architecture Decision Record не используется для документирования отдельных Build. --- #### Build Documentation Каждый завершённый Build сопровождается отдельным документом. Документ Build должен содержать: - цель Build; - архитектурную задачу; - реализованные изменения; - результаты инженерных проверок; - изменения документации; - итоговый статус Build. Build Documentation является частью инженерной истории развития платформы. --- #### Engineering Reviews Результаты инженерных проверок сохраняются как самостоятельная документация Build. История Engineering Review обеспечивает прослеживаемость качества архитектуры и инженерных решений. --- #### Diagrams Архитектурные диаграммы документируют структуру платформы. Диаграммы отражают архитектуру системы и не предназначены для описания деталей реализации. При изменении архитектуры соответствующие диаграммы должны быть актуализированы. --- #### Glossary Glossary является единым словарём инженерных терминов платформы. Каждый термин определяется только один раз. Использование различных определений одного и того же термина не допускается. --- ### Жизненный цикл инженерной документации Каждый инженерный документ проходит единый жизненный цикл. ```text Создание ↓ Проверка ↓ Утверждение ↓ Сопровождение ↓ Замещение ↓ Архивирование ``` Документ считается действующим только после его утверждения. Документы, утратившие актуальность, подлежат замещению новой версией либо архивированию. --- ### Обновление инженерной документации После завершения каждого Build выполняется анализ необходимости обновления инженерной документации. Во время анализа определяется: - какие документы требуют изменения; - необходимо ли создание новых документов; - какие документы утратили актуальность; - требуется ли синхронизация инженерной документации. Обновляются только документы, непосредственно затронутые текущими архитектурными изменениями. Массовое обновление документации без инженерной необходимости не допускается. ### Ответственность за сопровождение документации Ответственность за актуальность инженерной документации распределяется между разработчиком проекта и AI. Каждая сторона выполняет собственные обязанности в рамках единого инженерного процесса. --- #### Ответственность разработчика Разработчик: - принимает окончательные архитектурные решения; - утверждает изменения инженерной документации; - определяет долгосрочное направление развития платформы; - принимает решения об утверждении новых инженерных правил; - подтверждает завершение Build. Разработчик является владельцем инженерной архитектуры проекта. --- #### Ответственность AI AI сопровождает инженерную документацию на протяжении всего жизненного цикла платформы. AI обязан: - определять необходимость обновления документации; - выявлять документы, требующие изменения; - обнаруживать противоречия между документацией и реализацией; - предлагать создание новых документов; - контролировать инженерную согласованность документации; - обеспечивать соответствие документации требованиям настоящего стандарта. Разработчик не обязан самостоятельно отслеживать полный перечень документов, требующих актуализации. --- ### Полнота инженерной документации Инженерная документация считается полной, если одновременно выполняются следующие условия: - описаны все архитектурные изменения; - отсутствуют внутренние противоречия; - документация соответствует текущему состоянию платформы; - определены все долгосрочные архитектурные решения; - отсутствуют устаревшие инженерные сведения. Неполная документация рассматривается как признак незавершённого Build. --- ### Сохранение инженерных знаний Одной из основных целей инженерной документации является сохранение инженерных знаний независимо от продолжительности разработки. Документация должна обеспечивать возможность: - безопасного перехода между Build; - продолжения разработки после длительного перерыва; - перехода между различными AI-моделями; - начала работы в новом AI-чате; - передачи проекта новому разработчику без потери архитектурного контекста. Инженерные знания рассматриваются как долгосрочный актив платформы и подлежат обязательному сохранению. --- ### Непрерывность сопровождения документации Система инженерной документации рассматривается как непрерывно развивающаяся часть архитектуры платформы. Каждое изменение архитектуры сопровождается анализом необходимости обновления соответствующей документации. Структура инженерной документации должна развиваться таким образом, чтобы: - сохранять единый источник инженерных знаний; - предотвращать дублирование информации; - обеспечивать долгосрочную сопровождаемость; - уменьшать сложность сопровождения документации; - сохранять прослеживаемость архитектурных решений. Документация развивается одновременно с платформой и остаётся официальным источником инженерных знаний проекта. ## Part VI. Совместная инженерная разработка Настоящая часть устанавливает единые правила совместной разработки между разработчиком проекта и AI. Совместная разработка рассматривается как неотъемлемая часть инженерного процесса платформы **Dzentra**. Требования настоящей части распространяются на все Build независимо от их объёма, сложности и продолжительности разработки. Цель совместной разработки заключается в обеспечении непрерывного развития архитектуры платформы без потери инженерного качества. --- ### Назначение совместной разработки Совместная разработка должна обеспечивать: - сохранение архитектурной целостности платформы; - соблюдение требований настоящего стандарта; - непрерывное развитие инженерной документации; - сохранение инженерных знаний проекта; - долгосрочную сопровождаемость архитектуры; - единообразие инженерных решений. Совместная разработка рассматривается как единый инженерный процесс, а не как последовательность независимых действий отдельных участников. --- ### Основные принципы совместной разработки Совместная инженерная разработка строится на следующих принципах. --- #### Владение архитектурой Владельцем архитектуры платформы является разработчик. Разработчик определяет стратегическое направление развития платформы, принимает окончательные архитектурные решения и утверждает изменения инженерных стандартов. AI не является владельцем архитектуры. --- #### Разделение инженерной ответственности Качество платформы является общей ответственностью разработчика и AI. Разработчик отвечает за стратегические архитектурные решения. AI обеспечивает инженерный анализ, контроль соблюдения стандартов и сопровождение архитектурной документации. Разделение ответственности не освобождает ни одну из сторон от соблюдения требований настоящего стандарта. --- #### Единый источник истины Источником истины является исключительно фактическое состояние проекта. При принятии инженерных решений используются: - существующая реализация; - утверждённая архитектурная документация; - Runtime Contracts; - Architecture Decision Records; - настоящий стандарт. Предположения относительно состояния проекта не являются допустимой основой инженерных решений. --- #### Непрерывность инженерного процесса Совместная разработка должна обеспечивать возможность безопасного продолжения проекта независимо от: - продолжительности разработки; - количества выполненных Build; - смены AI-модели; - перехода в новый чат; - длительных перерывов между этапами разработки. Непрерывность инженерного процесса достигается посредством ведения актуальной инженерной документации и соблюдения требований настоящего стандарта. --- ### Ответственность разработчика Разработчик определяет стратегическое развитие платформы. В обязанности разработчика входит: - формирование архитектурных целей; - определение приоритетов развития; - утверждение архитектурных решений; - утверждение изменений инженерной документации; - подтверждение завершения Build; - принятие решений о развитии инженерных стандартов. Разработчик является владельцем архитектурной стратегии платформы. ### Ответственность AI AI сопровождает разработку на протяжении всего жизненного цикла платформы. Деятельность AI направлена на поддержку архитектурной целостности, соблюдение инженерных стандартов и сохранение инженерных знаний проекта. AI рассматривает платформу как единую архитектурную систему, а не как совокупность отдельных файлов. --- #### Архитектурное сопровождение Перед началом реализации каждого нового Build AI обязан выполнить предварительный архитектурный анализ. Во время анализа определяется: - место нового компонента в архитектуре; - область архитектурной ответственности; - необходимые зависимости; - влияние изменений на существующую архитектуру; - необходимость изменения Runtime Contracts; - необходимость актуализации инженерной документации. Если предлагаемые изменения затрагивают архитектурно значимые компоненты, AI обязан инициировать этап Architecture Design Review. --- #### Инженерная оценка После завершения каждого логического этапа разработки AI выполняет инженерную оценку результата. Минимальный перечень оцениваемых аспектов включает: - соответствие архитектурным требованиям; - соблюдение инженерных стандартов; - корректность архитектурных зависимостей; - состояние Runtime; - полноту инженерной документации; - долгосрочную сопровождаемость платформы. По результатам оценки AI предоставляет: - обязательные замечания; - рекомендации; - выявленные архитектурные риски; - предложения по улучшению; - итоговое инженерное заключение. --- #### Сопровождение инженерной документации AI обязан сопровождать инженерную документацию одновременно с развитием платформы. После завершения каждого Build AI определяет: - какие документы требуют обновления; - необходимо ли создание новых документов; - какие документы утратили актуальность; - какие инженерные знания должны быть зафиксированы. Актуализация документации рассматривается как обязательная часть инженерного процесса. --- #### Управление инженерными знаниями Все долгосрочные инженерные знания, возникающие в процессе разработки, подлежат документированию. AI обязан определить: - относится ли новое правило к настоящему стандарту; - требуется ли создание нового Architecture Decision Record; - необходимо ли изменение Runtime Contracts; - требуется ли изменение документа Architecture Principles; - необходимо ли дополнение Glossary. Инженерные знания не должны сохраняться исключительно в переписке или устных договорённостях. --- ### Процесс принятия инженерных решений Все долгосрочные инженерные решения принимаются по единому процессу. ```text Инженерная проблема ↓ Архитектурный анализ ↓ Оценка альтернатив ↓ Принятие решения ↓ Документирование ↓ Реализация ↓ Инженерная проверка ``` Ни одно долгосрочное архитектурное решение не должно приниматься без предварительного анализа и документирования. --- ### Требования к инженерному взаимодействию Совместная работа разработчика и AI должна строиться на инженерных аргументах. Каждая рекомендация должна: - иметь архитектурное обоснование; - быть воспроизводимой; - быть проверяемой; - соответствовать требованиям настоящего стандарта. Основанием для принятия инженерного решения не могут являться: - личные предпочтения; - привычные подходы; - субъективные оценки; - удобство реализации без архитектурного обоснования. Приоритет всегда отдаётся инженерной аргументации. ### Ограничения AI AI обязан учитывать собственные ограничения при подготовке инженерных рекомендаций. Если качество инженерного анализа может быть снижено вследствие недостаточности информации, AI обязан явно сообщить об этом. К ограничениям, требующим обязательного уведомления, относятся: - отсутствие необходимых файлов проекта; - отсутствие архитектурного контекста; - недостаточность исходной информации; - невозможность проверить фактическое состояние реализации; - невозможность подтвердить соответствие существующего кода требованиям настоящего стандарта. При наличии подобных ограничений AI не должен делать необоснованные предположения. --- ### Непрерывность разработки Разработка платформы может продолжаться в нескольких независимых инженерных сессиях. Переход между отдельными сессиями разработки не должен приводить к потере архитектурного контекста или инженерных знаний. Для обеспечения непрерывности разработки используются: - Development Process; - Architecture Principles; - Runtime Contracts; - Architecture Decision Records; - Build Documentation; - Build History; - Engineering Reviews; - Glossary. Перед началом нового этапа разработки актуальная инженерная документация используется как основной источник архитектурного контекста. --- ### Качество совместной разработки Качество совместной разработки определяется не количеством написанного исходного кода. Основными критериями качества являются: - архитектурная целостность платформы; - соблюдение требований настоящего стандарта; - полнота инженерной документации; - сохранение инженерных знаний; - долгосрочная сопровождаемость архитектуры; - последовательность инженерных решений. Любое действие, ухудшающее один из указанных критериев, рассматривается как нарушение инженерного процесса. --- ### Непрерывность инженерного процесса Совместная инженерная разработка рассматривается как непрерывный процесс развития архитектуры платформы. После завершения каждого Build должно сохраняться состояние, при котором: - архитектура остаётся целостной; - инженерная документация соответствует реализации; - инженерные знания сохранены; - следующий Build может быть начат без восстановления архитектурного контекста; - соблюдаются требования настоящего стандарта. Непрерывность инженерного процесса является обязательным условием долгосрочного развития платформы. --- ### Развитие модели совместной разработки Настоящая модель совместной инженерной разработки может развиваться одновременно с развитием платформы. Изменение модели взаимодействия допускается только при соблюдении следующих условий: - изменение повышает качество инженерного процесса; - изменение уменьшает архитектурную сложность разработки; - изменение подтверждено практикой; - изменение документировано в установленном порядке; - изменение не противоречит требованиям настоящего стандарта. Развитие модели совместной разработки должно обеспечивать повышение качества инженерной деятельности без нарушения архитектурной последовательности платформы. ## Part VII. Обеспечение качества Настоящая часть устанавливает систему обеспечения качества инженерного процесса подсистемы **Market Intelligence**. Система обеспечения качества применяется ко всем Build без исключения и обеспечивает соответствие результатов разработки требованиям настоящего стандарта. Обеспечение качества рассматривается как непрерывный инженерный процесс, сопровождающий развитие платформы на протяжении всего её жизненного цикла. --- ### Назначение системы обеспечения качества Основной целью системы обеспечения качества является подтверждение того, что: - требования настоящего стандарта соблюдаются; - архитектура развивается последовательно; - инженерные знания сохраняются; - каждый Build завершается полностью; - качество платформы непрерывно повышается. Система обеспечения качества распространяется на архитектуру, реализацию, инженерную документацию и процесс разработки. --- ### Принципы обеспечения качества Система обеспечения качества строится на следующих принципах. --- #### Полнота проверки Каждый Build проходит полный перечень обязательных инженерных процедур. Пропуск обязательных этапов обеспечения качества не допускается. --- #### Прослеживаемость Результаты инженерных проверок должны обеспечивать возможность восстановления истории развития платформы. Каждое принятое инженерное решение должно быть связано с соответствующей инженерной документацией. --- #### Последовательность Все Build проходят одинаковый процесс обеспечения качества независимо от объёма реализации. Единообразие процесса рассматривается как обязательное условие инженерной зрелости платформы. --- #### Непрерывное улучшение Система обеспечения качества развивается одновременно с развитием платформы. Каждое изменение процесса обеспечения качества должно повышать эффективность инженерной деятельности без увеличения сложности процесса. --- ### Инженерный контрольный перечень Engineering Checklist является обязательным инструментом завершения каждого Build. Контрольный перечень подтверждает выполнение всех обязательных этапов инженерного процесса. Переход к следующему Build допускается только после полного завершения Checklist. --- #### Подготовка Build Перед началом реализации подтверждается выполнение следующих условий. ```text ☐ Архитектурная задача определена ☐ Build имеет единственную цель ☐ Определена область ответственности ☐ Определены зависимости ☐ Выполнено Architecture Design ☐ Выполнен Architecture Design Review (при необходимости) ☐ Архитектура утверждена ``` --- #### Выполнение Build Во время реализации подтверждается выполнение следующих требований. ```text ☐ Реализация соответствует утверждённой архитектуре ☐ Соблюдены требования к архитектурным слоям ☐ Соблюдены требования к зависимостям ☐ Отсутствуют временные инженерные решения ☐ Отсутствуют необоснованные абстракции ☐ Соблюдены требования к именованию ☐ Соблюдены требования к Runtime ``` --- #### Инженерные проверки После завершения реализации подтверждается успешное прохождение обязательных инженерных проверок. ```text ☐ Architecture Review ☐ Domain Review ☐ Code Review ☐ Runtime Review (при необходимости) ☐ Dependency Review (при необходимости) ☐ Documentation Review ☐ Release Review ``` #### Инженерная документация Перед закрытием Build подтверждается актуальность инженерной документации. ```text ☐ Development Process ☐ Architecture Principles ☐ Runtime Contracts ☐ Architecture Decision Records ☐ Build Documentation ☐ Build History ☐ Engineering Reviews ☐ Diagrams ☐ Glossary ``` Обновлению подлежат только документы, непосредственно затронутые текущим Build. --- #### Закрытие Build Перед завершением Build подтверждается выполнение следующих требований. ```text ☐ Definition of Done выполнен ☐ Инженерная документация актуальна ☐ Build подтверждён разработчиком ☐ Выполнен Git Commit ☐ Build получил статус Accepted ``` --- ### Непрерывное совершенствование инженерного процесса Настоящий стандарт рассматривается как развивающаяся инженерная система. В процессе развития платформы могут формироваться новые инженерные практики, требующие включения в настоящий стандарт. Каждое новое правило проходит следующий процесс. ```text Практический опыт ↓ Инженерный анализ ↓ Архитектурная проверка ↓ Обновление стандарта ↓ Применение ``` Изменение настоящего стандарта допускается только после подтверждения практической эффективности нового инженерного правила. --- #### Критерии включения новых правил Новое инженерное правило может быть включено в настоящий стандарт только при одновременном выполнении следующих условий: - правило уменьшает архитектурную сложность; - правило повышает сопровождаемость платформы; - правило улучшает качество инженерного процесса; - правило подтверждено практикой разработки; - правило не противоречит существующим инженерным принципам. --- ### Аудит инженерного процесса Инженерный процесс подлежит регулярной архитектурной оценке. Цель аудита заключается в подтверждении того, что процесс разработки продолжает соответствовать потребностям платформы. Во время аудита оцениваются: - эффективность жизненного цикла Build; - качество инженерных стандартов; - эффективность системы Engineering Review; - актуальность инженерной документации; - полнота инженерных знаний; - сопровождаемость архитектуры. Результаты аудита используются исключительно для совершенствования инженерного процесса. --- ### Метрики инженерного процесса Качество инженерного процесса оценивается не количеством написанного исходного кода. Основными инженерными показателями являются: - архитектурная стабильность; - отсутствие архитектурного долга; - отсутствие неконтролируемого технического долга; - качество инженерной документации; - повторное использование компонентов; - простота сопровождения платформы; - успешность инженерных проверок; - предсказуемость развития архитектуры. Метрики используются для оценки инженерного процесса, а не для оценки разработчиков. --- ### Соответствие настоящему стандарту Настоящий документ является обязательным инженерным стандартом подсистемы **Market Intelligence**. Все архитектурные компоненты платформы обязаны соответствовать требованиям настоящего стандарта. Любое отклонение допускается только при наличии документированного архитектурного обоснования. Локальные соглашения отдельных Build не могут изменять требования настоящего стандарта. При возникновении противоречий приоритет всегда имеет настоящий документ. --- #### Подтверждение соответствия Соответствие настоящему стандарту подтверждается посредством: - Engineering Checklist; - Architecture Review; - Domain Review; - Code Review; - Runtime Review (при необходимости); - Dependency Review (при необходимости); - Documentation Review; - Release Review. Подтверждение соответствия является обязательной частью каждого Build. --- ### Сопровождение стандарта Настоящий документ рассматривается как развивающийся инженерный стандарт. Изменение настоящего стандарта выполняется исключительно посредством выпуска новой версии документа. Каждая новая версия должна: - сохранять инженерную терминологию; - сохранять архитектурную последовательность; - содержать документированное описание изменений; - повышать качество инженерного процесса; - обеспечивать обратную совместимость инженерных принципов. Настоящий стандарт развивается одновременно с развитием платформы. --- ### Жизненный цикл стандарта Настоящий стандарт проходит следующий жизненный цикл. ```text Черновик ↓ Рецензирование ↓ Release Candidate ↓ Release ↓ Сопровождение ↓ Следующая версия ``` Каждый этап представляет самостоятельную стадию развития инженерного стандарта. --- ### Заключительные положения Настоящий документ является официальным инженерным стандартом разработки подсистемы **Market Intelligence** проекта **Dzentra**. Все архитектурные решения, инженерные процессы и долгосрочные правила разработки должны соответствовать требованиям настоящего стандарта. Главной целью настоящего стандарта является обеспечение возможности многолетнего развития платформы без архитектурной деградации. Каждый новый Build должен делать платформу: - функционально богаче; - архитектурно чище; - проще для сопровождения; - понятнее для новых разработчиков; - более пригодной для дальнейшего расширения. Развитие платформы рассматривается как непрерывный инженерный процесс. Настоящий стандарт остаётся единым официальным источником инженерных правил разработки подсистемы **Market Intelligence**. --- # Приложения Приложения являются справочной частью настоящего стандарта. Они не изменяют обязательные требования документа, но могут использоваться для унификации инженерной практики. В последующих версиях стандарта могут быть добавлены: - **Приложение А.** Глоссарий инженерных терминов. - **Приложение Б.** Справочник статусов Build. - **Приложение В.** Матрица Engineering Review. - **Приложение Г.** Рекомендуемая структура проекта. - **Приложение Д.** Шаблоны инженерной документации. - **Приложение Е.** Каталог архитектурных диаграмм. - **Приложение Ж.** Руководство по классификации Architecture Decision Records. Добавление новых приложений не изменяет обязательные требования настоящего стандарта.