Почему ваша архитектура ломается, и как этого избежать через онтологию данных.

Представьте: один отдел называет «клиентом» потенциального покупателя, другой — юридическое лицо в договоре, а в базе данных живёт учётная запись пользователя. Новые требования взрывают казалось бы стабильную систему, потому что её ядро - не код, а семантический хаос из противоречащих друг другу смыслов.

Решение - метод «параллельных веток». Он позволяет до написания первой строчки кода найти устойчивую онтологию - формальную модель смыслов вашей предметной области. Эта практика опирается на принципы Domain-Driven Design и семантического веба, которые десятилетиями применяются в самых сложных проектах.

🧭 Суть метода за 30 секунд.

Зафиксировать хаос: соберите все термины и их значения из разных контекстов.

Создать альтернативы - постройте три гипотезы ядра системы (объектную, событийную, процессную).

Протестировать на прочность - прогнать каждую через ключевые бизнес-сценарии.

Отсечь слабые - применить формальные «канареечные тесты» для объективного выбора.

Формализовать - зафиксировать выжившую модель как контракт о смыслах.

Транслировать в код и только затем превращать её в схемы БД, API и границы сервисов.

Ключевой принцип - не искать одну идеальную модель, а быстро отсекать слабые, найдя самую устойчивую. 🔍 Шаг 1. Семантическое поле: собрать и обезвредить.

Прежде чем рисовать диаграммы, соберите словарь. Задокументируйте все ключевые термины, которые используют заказчики, эксперты и пользователи.

Как это сделать:

Источники: интервью, пользовательские истории, письма, глоссарии, ТЗ.

Фиксация: Для каждого термина запишите: Кто (роль), Контекст (процесс), Фактическое значение.

Пример семантического поля: Термин Кто (роль) Контекст Фактическое значение Клиент Менеджер по продажам Ведение сделки Потенциальный покупатель (лид) Клиент Бухгалтер Начисление платежа Юридическое лицо (контрагент) Заказ Отдел логистики Доставка Физический груз, набор позиций Заказ Финансовый отдел Оплата Финансовое обязательство, счёт

Железное правило: Если один термин в разных контекстах означает разное — в онтологии это два разных понятия. Игнорирование этого — корень будущих проблем. 🌳 Шаг 2. Три параллельные ветки: создать альтернативы

Не залипайте на первой модели. Создайте три принципиально разные гипотезы ядра системы.

Типовые оси для веток:

Объектно-ориентированная. Ядро - ключевой объект (договор, продукт). Акцент на состоянии и атрибутах.

Событийно-ориентированная. Ядро - неизменяемый факт (договор подписан, платёж поступил). Система - это лента событий.

Процессно-ориентированная. Ядро - процесс (Согласование) или документ с жизненным циклом (Заявка). Акцент на этапах и переходах.

Пример из EdTech для сценария «студент сдаёт ДЗ»:

Объектная ветка - Студент -> сдаёт -> Работа (статус меняется на "на проверке").

Событийная ветка - возникает факт работа сдана (содержит ссылки на студента и задание).

Процессная ветка - процесс выполнения задания переходит в этап проверка.

Цель - не выбрать самую красивую, а найти наиболее устойчивую.

🐦 Шаг 3. Канареечные тесты: отсечь объективно.

Чтобы выбор был не субъективным, а формальным, используйте строгие критерии.

🚨 Красные флаги (слабая модель):

Избыточная абстракция - для базового сценария нужно >3 уровней вложенности.

Циклические зависимости - сущности ссылаются друг на друга по кругу.

Костыли - на каждый новый кейс нужны специальные флаги или сущности-заглушки.

🟢 Зелёные сигналы (сильная модель):

Линейное расширение - новые требования добавляются через расширение (новые атрибуты, типы событий), а не переделку ядра.

Семантическая ясность - модель одинаково понятна разработчику, аналитику и эксперту.

Процесс: Прогоните 2-3 ключевых сценария через все три ветки. Та, что чаще требует костылей, — кандидат на отсечение.

📐 Шаг 4. Формализация: создать контракт.

После выбора основной ветки формализуйте её в декларативный контракт, а не технический дизайн.

Что фиксировать:

Классы (концепты): договор, сторона, платёж.

Свойства - у договора есть номер, дата, сумма.

Отношения - договор заключает сторона, договор имеет платёж.

Правила - платёж не может существовать без договора в статусе "активен".

Эту модель можно записать в YAML или использовать редактор Protégé для визуализации и проверки логической целостности.

⚙ Шаг 5. От смыслов к системе: как онтология формирует архитектуру

Когда онтология утверждена, она перестаёт быть абстракцией и начинает диктовать конкретные архитектурные решения. Это не про механическое сопоставление, а про выявление логических следствий.

1. Классы и свойства определяют границы сервисов (Bounded Contexts).

Логика: классы связанные сильными частыми отношениями, образуют естественные кластеры - ограниченные контексты из DDD. Это кандидаты в отдельные микросервисы или модули.

Пример: если в онтологии заказ, позиция заказа и резерв на складе тесно связаны, то они с высокой вероятностью войдут в один сервис - Order Service. Свойства этих классов становятся полями его API-контрактов и схемой его базы данных.

2. Отношения диктуют тип связи между компонентами.

Логика - характер связи между классами из разных контекстов определяет способ их интеграции.

Сильная, композиционная связь (Заказ содержит Платёж) → Может указывать на общий контекст или на синхронный вызов API (REST/gRPC).

Слабая, событийная связь (Заказ инициирует Доставку) → Чёткий кандидат на асинхронную коммуникацию через события.

Пример: отношение договор → имеет → платёж внутри одного контекста реализуется как внешний ключ в БД. Отношение заказ оформлен → инициирует → уведомление клиента между контекстами реализуется как сообщение в шине событий (Kafka).

3. Правила становятся контрактами и контролем целостности

Логика: бизнес правила из онтологии распределяются по уровням системы, обеспечивая согласованность.

Пример: правило «платёж не может быть создан без действующего договора» транслируется в:

Уровень API: валидация входящего запроса на создание платежа.

Уровень БД: FOREIGN KEY CONSTRAINT или CHECK.

Уровень доменной логики: вызов метода Contract.canAcceptPayment перед созданием объекта Payment.

4. События - это явные описатели изменений состояния

Логика: ключевые изменения состояния (договор подписан, платёж проведён) становятся событиями - основным языком межсервисной коммуникации.

Пример: событие платёж поступил - это не просто «сообщение в шине». Это контракт на данные (payload), который должен быть однозначно понят всеми подписчиками (сервис аналитики, сервис нотификаций, сервис бухгалтерии). Его структура напрямую выводится из свойств классов платёж и договор в онтологии.

🧰 Инструменты и что читать дальше:

Для моделирования: Protégé — свободный промышленный редактор онтологий от Стэнфорда.

Для работы в коде: Apache Jena — фреймворк для работы с RDF, OWL и SPARQL.

Теория: Эрик Эванс, "Domain-Driven Design" (библия DDD). Вон Вернон, "Implementing Domain-Driven Design" для практики.

Практика: Ищите кейсы по применению онтологий в интеграции данных и построении семантических слоёв в микросервисной архитектуре — это актуальный тренд.

🎯 Итог:

Проблемы сложных систем - это проблемы смыслов. Метод параллельных веток - не про создание идеальной модели с первого раза. Он про системный поиск самой устойчивой структуры через быстрое создание и объективное уничтожение альтернатив. Это инвестиция в этапе проектирования, которая многократно окупается на этапе роста и изменений системы.