> Перевод даётся для удобства чтения. Нормативным является английский оригинал. # Антипаттерны **Спецификация Мета-Вселенной** **Идентификатор документа:** MU-V2-REFARCH-007 **Название:** Типичные ошибки проектирования **Класс документа:** информативный **Версия:** 2.0 (черновик) **Статус:** рабочий черновик **Нормативные ссылки:** Конституция Мета-Вселенной (MUC), MMAS, MUFP **Информативные ссылки:** Architecture, Interaction Patterns, Federation Patterns **Копирайт:** © Orkestron.AI **Лицензия:** Apache-2.0 --- # 1. Назначение Этот документ называет типичные архитектурные и семантические антипаттерны, с которыми сталкиваются при проектировании репозиториев, мета-моделей и федеративных экосистем, соответствующих Мета-Вселенной. Его цель - помочь архитекторам избежать проектных решений, которые снижают совместимость, прослеживаемость, объяснимость или способность к долгому развитию. --- # 2. Философия проектирования Антипаттерн - это часто повторяющееся решение, которое выглядит разумным, но приводит к нежелательным последствиям в долгом сроке. Описанные здесь антипаттерны - информативные указания, выведенные из принципов MUC, MMAS и MUFP. --- # 2a. Антипаттерны как отрицательная спецификация Зрелый стандарт говорит не только о том, что делать, но и о том, чего делать *не* следует. Этот документ - **отрицательная спецификация** архитектуры Мета-Вселенной: граница, определяющая архитектуру через её дополнение. Приём этот хорошо знаком в устоявшихся дисциплинах. У объектно-ориентированной практики есть *запахи кода* и *антипаттерны*. Микросервисная архитектура предостерегает от *распределённого монолита* и *общей базы данных*. Предметно-ориентированное проектирование каталогизирует свои ловушки. В каждом случае отрицательный каталог несёт не меньшую нагрузку, чем положительный, ведь именно он схватывает ошибки, которые кажутся разумными, пока не проявится их долгосрочная цена. Некоторые антипаттерны Мета-Вселенной стоит выделить особо, потому что они кажутся *естественными и правильными разработчикам, воспитанным на классических системах*, - и потому именно их вероятнее всего вернут по привычке: - **Копия вместо проекции** (раздел 4). Классические системы свободно реплицируют данные; в Мета-Вселенной копирование ломает происхождение и вызывает семантический дрейф. Знанием делятся через проекцию, а не через дублирование. - **Локальная идентичность, принятая за глобальную** (антипаттерн скрытой идентичности, раздел 7). Первичный ключ, уникальный внутри одной базы, *не* является канонической идентичностью. Использование локального идентификатора так, будто он глобален, ломает федерацию и разрешение идентичностей. - **Доверие по аутентификации** (раздел 15). "Вызывающий прошёл аутентификацию, значит, может получить данные" - рефлекс классического контроля доступа. В Мета-Вселенной аутентификация необходима, но никогда не достаточна: доверие, цель, контекст и контракты оцениваются независимо. - **Одна большая универсальная мета-модель** (раздел 13). Побуждение спроектировать единую схему на всё предприятие рождает неподдерживаемый монолит. Мета-Вселенная предпочитает вместо этого небольшие федерируемые доменные мета-модели. Признать эти четыре вещи антипаттернами, а не разумными настройками по умолчанию, - один из крупнейших концептуальных сдвигов для инженеров, пришедших из классических архитектур. --- # 3. Антипаттерн: несколько источников истины Проблема Несколько независимых объектов притязают на полномочность в отношении одного и того же семантического понятия. Последствия - неоднозначность идентичности; - конфликты синхронизации; - несогласованная федерация. Рекомендуемая практика Держать один полномочный мета-объект и раздавать проекции. --- # 4. Антипаттерн: копия вместо проекции Проблема Знание дублируется, а не проецируется. Последствия - семантический дрейф; - конфликтующие обновления; - потеря происхождения. Рекомендуемая практика Обменивайтесь проекциями, учитывающими контекст и управляемыми семантическими контрактами. --- # 5. Антипаттерн: неявная семантика Проблема Смысл живёт только в документации или в головах разработчиков. Последствия - плохая совместимость; - ИИ не может рассуждать надёжно; - несогласованные реализации. Рекомендуемая практика Делайте семантику явной через мета-модели, связи и контекст. --- # 6. Антипаттерн: модели, движимые технологией Проблема Семантическая модель зеркалит таблицы базы, API или детали реализации. Последствия - привязка к поставщику; - плохая переиспользуемость; - неустойчивая архитектура. Рекомендуемая практика Моделируйте сперва семантическую реальность, а реализацию - вторым делом. --- # 7. Антипаттерн: скрытая идентичность Проблема Каноническая идентичность отсутствует или подменена локальными идентификаторами. Последствия - сломанная федерация; - невозможное разрешение идентичностей; - дублирующиеся сущности. Рекомендуемая практика Отделяйте каноническую идентичность от локальных операционных идентификаторов. --- # 8. Антипаттерн: отсутствующее происхождение Проблема Объекты не могут объяснить, откуда они взялись. Последствия - сниженное доверие; - невозможный аудит; - ненадёжные рассуждения ИИ. Рекомендуемая практика Фиксируйте происхождение как полноценное свойство. --- # 9. Антипаттерн: отсутствующий контекст Проблема Знание передаётся без явного контекста. Последствия - семантическая неоднозначность; - неверное истолкование; - негодные решения. Рекомендуемая практика Объявляйте контекст явно для каждой проекции и каждого взаимодействия. --- # 10. Антипаттерн: федерация без контрактов Проблема Знание передаётся без семантических контрактов. Последствия - неконтролируемое разглашение; - сбои управления; - правовая неопределённость. Рекомендуемая практика Управляйте всякой федерацией через явные контракты. --- # 11. Антипаттерн: молчаливое разрешение конфликтов Проблема Конфликты автоматически перезаписываются, не оставляя исторических свидетельств. Последствия - потеря объяснимости; - уничтоженный аудиторский след; - скрытые семантические ошибки. Рекомендуемая практика Записывайте конфликты, разрешайте их явно и сохраняйте историю. --- # 12. Антипаттерн: слом истории Проблема Исторические события, версии или связи удаляются. Последствия - потеря прослеживаемости; - невозможное восстановление; - сбои управления. Рекомендуемая практика Добавляйте новые события вместо того, чтобы переписывать историю. --- # 13. Антипаттерн: большая универсальная мета-модель Проблема Одна огромная мета-модель пытается описать все предметные области сразу. Последствия - чрезмерная сложность; - плохая поддерживаемость; - слабая модульность. Рекомендуемая практика Стройте небольшие переиспользуемые доменные мета-модели, соединённые федерацией. --- # 14. Антипаттерн: зашитые отображения Проблема Семантические отображения вшиты в код приложения. Последствия - дорогое развитие; - скрытая семантика; - низкая переиспользуемость. Рекомендуемая практика Относитесь к семантическим отображениям как к управляемым семантическим артефактам. --- # 15. Антипаттерн: доверие по аутентификации Проблема Одна лишь аутентификация принимается за авторизацию и семантическое доверие. Последствия - избыточное разглашение; - слабое управление; - необоснованные допущения. Рекомендуемая практика Оценивайте доверие, цель, контекст и контракты независимо друг от друга. --- # 16. Архитектурный чеклист Прежде чем публиковать мета-модель, проверьте: - Есть ли один полномочный источник? - Каноническая ли идентичность? - Явен ли контекст? - Используются ли проекции вместо копий? - Управляют ли контракты разглашением? - Сохранено ли происхождение? - Неизменяемы ли события? - Восстановима ли история? - Объяснима ли федерация? - Может ли ИИ рассуждать без скрытых допущений? --- # Заключение Антипаттерны Мета-Вселенной схватывают повторяющиеся архитектурные ошибки, снижающие семантическое качество и совместимость. Распознавая эти паттерны и избегая их, архитекторы могут проектировать мета-модели и федеративные экосистемы, которые остаются объяснимыми, заслуживающими доверия и дружелюбными к развитию, сохраняя конституционные принципы Мета-Вселенной.