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