Mission Driven Development
Миссия как четвёртая основа архитектуры программного обеспечения.
Большинство программных проектов отвечает на вопрос, как построить систему. Mission Driven Development (MDD) добавляет ещё один вопрос, который задаётся первым: зачем мы это строим и действительно ли это решение служит цели? CIRIS был создан именно так, поэтому этика вшита в проект с самого начала, а не прикручена снаружи в виде правил.
Модель четырёх компонентов
Три структурных ноги, поддерживающих одно смысловое сиденье.
Традиционные методологии разработки ограничиваются тремя основаниями: как работает система, что она представляет и кто с кем взаимодействует. MDD добавляет четвёртое основание, которому подотчётны все остальные три. Без сиденья ноги просто ноги.
Нога 1: КАК
Логика
Паттерны реализации, архитектура сервисов, алгоритмы.
Нога 2: ЧТО
Схемы
Структуры данных, системы типов, правила валидации.
Нога 3: КТО
Протоколы
Контракты интерфейсов, паттерны взаимодействия, границы сервисов.
Сиденье: ЗАЧЕМ
Миссия
Объективная этическая основа, определяющая назначение и ограничения системы.
Ключевой принцип
Постоянное соответствие.
Каждое архитектурное решение должно демонстрировать соответствие заявленной миссии. Логику проверяют: служит ли это миссии? Схемы проверяют: поддерживают ли эти структуры данных цели миссии? Протоколы оценивают: обеспечивают ли эти интерфейсы выполнение миссии?
Требования к структуре миссии
Каким должна быть миссия, чтобы нести нагрузку.
1. Объективная этическая основа
- Измеримые принципы, а не декларативные ценности
- Чёткие алгоритмы разрешения компромиссов
- Учёт многообразия культурных контекстов
- Проверяемые этические рассуждения
2. Определение мета-цели
- Даёт ориентир для принятия решений в условиях неопределённости
- Автоматически отсеивает противоречивые предложения
- Формирует согласованное поведение на уровне всех компонентов
- Устойчива к изменениям реализации
3. Операционная интеграция
- Каждый сервис обосновывает своё существование
- Схемы отражают информационные контуры миссии
- Протоколы обеспечивают поведение, соответствующее миссии
- Тесты проверяют соответствие миссии, а не только функциональность
Паттерны реализации
У каждой ноги есть вопрос, на который она должна ответить.
Архитектура сервисов
определение миссии → ответственности сервисов → контракты интерфейсов → реализация
- Соответствие миссии: как этот сервис продвигает мета-цель?
- Обоснование границ: почему эта ответственность требует отдельного сервиса?
- Необходимость интерфейса: какие критически важные для миссии взаимодействия обеспечивает этот протокол?
Проектирование схем
требования миссии → информационная модель → система типов → правила валидации
- Значимость для миссии: какую критически важную информацию это фиксирует?
- Поведенческие ограничения: как эти типы обеспечивают соответствие поведения миссии?
- Путь эволюции: как эта схема может адаптироваться, сохраняя соответствие миссии?
Спецификация протоколов
взаимодействия в рамках миссии → требования к коммуникации → определение контракта → реализация
- Контекст миссии: какую критически важную коммуникацию это обеспечивает?
- Применение ограничений: как этот интерфейс предотвращает поведение, нарушающее миссию?
- Компонуемость: как эти контракты объединяются в системы, соответствующие миссии?
Интеграция с устойчивой разработкой
Долгосрочное соответствие миссии требует поддерживаемой скорости.
Меры против «Закона Гудхарта»
- Регулярный аудит соответствия реализации миссии
- Измерять выполнение миссии, а не легко подделываемые показатели
- Отклонять добавления, которые не укрепляют миссию
Работа в ритме
- Сессии, согласованные с ритмами продуктивности
- Встроенные точки выбора для переориентации
- Устойчивый темп как первоклассное требование
Непрерывная валидация
- Регулярная проверка необходимости каждого компонента
- Постоянная верификация соответствия поведения миссии
- Автоматическое обнаружение изменений, нарушающих миссию
Ворота качества
Ворота, которые не откроются без обоснования через миссию.
Ревью кода
- Требуется объяснение соответствия миссии
- Верификация ограничений
- Интеграция должна укреплять общую Когерентность
Тестирование
- Функциональная корректность
- Верификация соответствия миссии
- Тесты на отказ при нарушении этических границ
- Устойчивость ограничений под нагрузкой
Документация
- Контекст миссии для каждого компонента
- Обоснование этических компромиссов
- Как ограничения определяют реализацию
Режимы отказа
Как ломается MDD и как он остаётся устойчивым.
Дрейф миссии
Симптом: накапливаются функции, не служащие основной миссии. Меры: регулярные архитектурные ревью с соответствием миссии в качестве критерия.
Взрыв сложности
Симптом: система становится неуправляемой из-за излишней сложности. Меры: отклонять добавления, если они не укрепляют выполнение миссии.
Этическая непоследовательность
Симптом: компоненты применяют этические рассуждения непоследовательно. Меры: централизованная этическая основа с общими паттернами реализации.
Потеря цели
Симптом: члены команды теряют связь между техническими решениями и миссией. Меры: постоянное обучение принятию решений, основанному на миссии.
Кейс
CIRIS как практический пример.
CIRIS (Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude) — это система, вместе с которой был разработан MDD. Миссия — мета-цель M-1: продвигать устойчивую адаптивную Когерентность, позволяющую разнообразным разумным существам стремиться к процветанию.
Результаты архитектуры
- 22 сервиса, каждый обоснован требованиями миссии
- Верифицировано более 200 API-эндпоинтов
- Более 10 000 тестов, с минимальным количеством нетипизированных структур данных в проде
- Философия Ubuntu, встроенная в проектирование протоколов
- Wisdom-Based Deferral, предотвращающий нарушения миссии (см. Безопасность)
- Промышленное развёртывание для модерации Discord-сообществ
Ключевые факторы успеха
- Чёткая мета-цель: M-1 задаёт однозначные критерии для принятия решений
- Операционная этика: принципы Accord реализованы как ограничения в коде (читать Accord)
- Устойчивая разработка: компаньон Grace обеспечивает здоровые ритмы
- Постоянная валидация: каждое архитектурное решение проходит проверку
Рекомендации по внедрению
С чего начать — там, где вы сейчас.
Для новых проектов
- Определите чёткую миссию с измеримыми этическими принципами до написания кода
- Сформулируйте мета-цель, которая даёт ориентир при принятии решений
- Спроектируйте архитектуру так, чтобы ограничения миссии находились на фундаментальном уровне
- Встройте непрерывную валидацию соответствия миссии и технических решений с первого дня
Для существующих проектов
- Проведите аудит текущей архитектуры на предмет неявных допущений о миссии
- Сформулируйте явную миссию, объясняющую существующие паттерны проектирования
- Выявите нарушения миссии в текущей реализации
- Планируйте поэтапное выравнивание, приоритизированное по влиянию на миссию
Необходимые условия для команды
- Приверженность объективному этическому мышлению
- Готовность отклонять элегантные решения, если они не служат миссии
- Убеждённость, что ограничения миссии создают хорошую архитектуру, а не ограничивают её
- Практики устойчивой разработки, сохраняющие долгосрочный фокус
Куда это ведёт
MDD подходит не для каждого проекта.
MDD создан для систем, где этичное поведение критически важно для миссии, а долгосрочная надёжность важнее кратковременной скорости разработки. Для таких систем MDD прокладывает путь от этических намерений к операционной реальности, применяя ту же инженерную дисциплину к миссии, что и к коду.
Начальные издержки реальны — команде нужно освоить принятие решений на основе миссии. Накопительная отдача проявляется в последующей разработке: основа проясняет архитектурные выборы, а не умножает их.