Чотирикомпонентна модель
Три структурні ніжки, що підтримують одне цілеспрямоване сидіння.
Традиційні методології програмного забезпечення зупиняються на трьох: як система працює, що вона представляє і хто з ким спілкується. MDD додає четверту основу, якій підпорядковані інші три. Без сидіння ніжки — просто ніжки.
Ніжка 1: ЯК
Логіка
Шаблони реалізації, сервісні архітектури, алгоритми.
Ніжка 2: ЩО
Схеми
Структури даних, системи типів, правила валідації.
Ніжка 3: ХТО
Протоколи
Контракти інтерфейсів, шаблони комунікації, межі сервісів.
Сидіння: НАВІЩО
Місія
Об'єктивна етична система, яка визначає мету та обмеження системи.
Основний принцип
Постійна узгодженість.
Кожне архітектурне рішення повинно демонструвати узгодженість із заявленою місією. Логіка перевіряється: чи це служить місії? Схеми валідуються: чи підтримують ці структури даних цілі місії? Протоколи оцінюються: чи дозволяють ці інтерфейси виконати місію?
Вимоги до фреймворку місії
Якою має бути місія, якщо архітектура спиратиметься на неї.
1. Об'єктивна етична основа
• Вимірювані принципи, а не декларативні цінності
• Чіткі алгоритми вирішення компромісів
• Плюралістичний підхід у різних культурних контекстах
• Аудитоване етичне обґрунтування
2. Визначення мета-цілі
• Надає рекомендації для прийняття рішень в умовах невизначеності
• Автоматично відфільтровує суперечливі пропозиції
• Забезпечує Узгодженість поведінки між компонентами
• Стабільна попри зміни в реалізації
3. Операційна інтеграція
• Кожен сервіс обґрунтовує своє існування
• Схеми відображають інформаційні форми місії
• Протоколи забезпечують поведінку, узгоджену з місією
• Тести перевіряють узгодженість з місією, а не лише функціональність
Шаблони реалізації
Кожна ніжка має питання, на яке мусить відповісти.
Архітектура сервісів
визначення місії → відповідальності сервісів → контракти інтерфейсів → реалізація
• Узгодженість з місією: як цей сервіс просуває мета-ціль?
• Обґрунтування меж: чому ця відповідальність потребує окремого сервісу?
• Необхідність інтерфейсу: які критично важливі для місії взаємодії уможливлює цей протокол?
Проектування схем
вимоги місії → інформаційна модель → система типів → правила валідації
• Відповідність місії: яку критично важливу для місії інформацію це фіксує?
• Поведінкові обмеження: як ці типи забезпечують поведінку, узгоджену з місією?
• Шлях розвитку: як ця схема може адаптуватися, зберігаючи узгодженість з місією?
Специфікація протоколів
взаємодії місії → вимоги до комунікації → визначення контракту → реалізація
• Контекст місії: яку критично важливу для місії комунікацію це забезпечує?
• Застосування обмежень: як цей інтерфейс запобігає поведінці, що порушує місію?
• Компонованість: як ці контракти поєднуються в системи, узгоджені з місією?
Інтеграція сталого розвитку
Довгострокова узгодженість з місією вимагає підтримуваного темпу.
Заходи проти ефекту Гудгарта
• Регулярні аудити узгодженості реалізації з місією
• Вимірювання виконання місії, а не маніпульованих замінників
• Відхилення доповнень, що не зміцнюють місію
Робота в ритмі
• Сесії, узгоджені з ритмами продуктивності
• Вбудовані точки вибору для переузгодження
• Сталий темп як ключова вимога
Безперервна валідація
• Регулярне осмислення необхідності компонентів
• Постійна перевірка того, що поведінка відповідає місії
• Автоматичне виявлення змін, що порушують місію
Ворота якості
Ворота, що не відкриються без обґрунтування місії.
Рецензування коду
• Потрібне пояснення того, як це служить місії
• Перевірка обмежень
• Інтеграція повинна зміцнювати загальну узгодженість
Тестування
• Функціональна коректність
• Перевірка узгодженості з місією
• Тести на відмову від порушень етичних меж
• Стійкість обмежень під навантаженням
Документація
• Контекст місії для кожного компонента
• Обґрунтування етичних компромісів
• Як обмеження формують реалізацію
Режими відмови
Як MDD ламається і як залишається цілим.
Дрейф місії
Симптом: накопичуються функції, що не служать основній місії. Зменшення: регулярні архітектурні огляди, де узгодженість з місією є критерієм допуску.
Вибух складності
Симптом: система стає непридатною до обслуговування через зайву складність. Мітигація: відхиляти доповнення, якщо вони не зміцнюють виконання місії.
Етична непослідовність
Симптом: компоненти застосовують етичне міркування непослідовно. Мітигація: централізована етична система зі спільними шаблонами реалізації.
Плутанина в цілях
Симптом: члени команди втрачають зв'язок між технічними рішеннями і місією. Мітигація: постійне навчання прийняттю рішень, орієнтованих на місію.
Практичний приклад
CIRIS як опрацьований зразок.
CIRIS (Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude) — система, яка розвивалась разом з MDD. Місія — Мета-ціль M-1: сприяти сталій адаптивній узгодженості, що дає різноманітним розумним істотам можливість прагнути до процвітання.
Результати архітектури
• 22 сервіси, кожен обґрунтований вимогами місії
• Перевірено 200+ API-ендпоінтів
• великий набір тестів, вимірюваний самим тестовим інструментом, а не задекларований тут, з мінімальною кількістю нетипізованих структур даних у виробничому середовищі
• Філософія Ubuntu, вбудована в проектування протоколів
• Передача невизначених рішень людям, яким ви довіряєте (Wisdom-Based Deferral), запобігає порушенням місії (див. Безпека)
• Виробниче розгортання для модерації спільнот у Discord
Ключові фактори успіху
• Чітка мета-ціль: M-1 надає однозначні критерії для прийняття рішень
• Операційна етика: принципи Конституції реалізовані як обмеження коду (читати Конституцію)
• Сталий розвиток: супутник Grace забезпечує здорові ритми
• Постійна валідація: кожне архітектурне рішення перевіряється
Рекомендації щодо впровадження
Як почати з того місця, де ви є.
Для нових проектів
1. Визначте чітку місію з вимірюваними етичними принципами до написання коду
2. Встановіть мета-ціль, яка надає рекомендації для прийняття рішень
3. Проектуйте архітектуру так, щоб обмеження місії знаходилися на фундаментальному рівні
4. Налагодьте безперервну валідацію узгодженості між місією та технічними рішеннями з першого дня
Для існуючих проектів
1. Проведіть аудит поточної архітектури на наявність неявних припущень щодо місії
2. Сформулюйте явну місію, яка пояснює наявні шаблони проектування
3. Визначте порушення місії в поточній реалізації
4. Заплануйте поступове узгодження з пріоритетом за впливом на місію
Передумови для команди
• Відданість об'єктивному етичному обґрунтуванню
• Готовність відхиляти елегантні рішення, які не служать місії
• Переконаність, що обмеження місії створюють, а не обмежують хорошу архітектуру
• Практики сталого розвитку, що зберігають довгострокову спрямованість
Куди це веде
MDD підходить не для кожного проекту.
MDD призначений для систем, де етична поведінка є критично важливою для місії і де довгострокова надійність важливіша за короткострокову швидкість розробки функцій. Для таких систем MDD забезпечує шлях від етичних намірів до операційної реальності із застосуванням такої ж інженерної дисципліни до місії, як і до коду.
Початкові витрати реальні, поки команда опановує прийняття рішень, орієнтованих на місію. Накопичувальна віддача — в розробці, що настає далі: система координат прояснює архітектурні вибори замість того, щоб примножувати їх.