Ubiquitous Language: почему ваш код врёт бизнесу (и сколько это стоит)
Бизнес называет это "claim", в коде класс Request, аналитик пишет "обращение". Три слова про одну сущность – и каждый разговор это перевод. По данным twoday, 30–50% усилий разработки уходит на переделку из-за непонятых требований. Это translation cost – налог, который снимает Ubiquitous Language.
🧭 Единый язык – ядро DDD
Domain-Driven Design ставит в центр системы доменную модель: код моделирует реальность бизнеса, оставляя структуру таблиц и удобство фреймворка на периферии. У подхода два уровня.
🔹 Стратегический – карта проблемы: единый язык, границы Bounded Context и связи между ними.
🔹 Тактический – форма кода внутри границы: entities, value objects, агрегаты, репозитории. Kia Raad: архитектура – это сцена, а DDD – сценарий и режиссёрские заметки на ней.
Ubiquitous Language держит всю конструкцию. Эванс в ретроспективе сместил акценты: "Ubiquitous Language, Context Mapping и Core Domain – в центре, агрегаты на близкой орбите".
Тактика без стратегии превращается в DDD-Lite: классы Aggregate и Repository, рассыпанные по кодовой базе, дают все накладные расходы без единой выгоды. Поэтому язык первичен.
🗣 Язык важнее красивых классов
Ubiquitous Language – это дисциплина. Слова бизнеса становятся именами классов, методов, событий и тестов.
Цель Эванса: доменный эксперт читает claim.Submit() и подтверждает поведение без переводчика. Анемичный people.Update(name, email) молчит о домене, а client.ChangeEmail() повторяет фразу "изменить email клиента".
🚧 "Ubiquitous" обманывает: язык локален
Главная ловушка – единый корпоративный словарь на всю компанию: полная унификация модели большой системы нерентабельна. Слово "Product" имеет до пяти значений – оффер, покупка, позиция в заказе, триггер рибейта, объект рейтинга.
Язык повсеместен только внутри одного Bounded Context. Следствия:
🔸 Глоссарии называют свой контекст: "Sales UL", "Billing UL"
🔸 На "Customer" обязаны ответить: "в каком контексте?"
🔸 Границу контекста выдаёт язык – Greg Young: ищите, где слова меняют значение
🔥 Как строить язык на практике
🔹 Event Storming до первого спринта. Соберите бизнес и инженеров. Один пишет "Order Placed", другой "Order Created" про одно событие – разногласие дешевле снять сейчас, чем когда оно станет двумя классами.
🔹 Начинайте с событий. События в прошедшем времени (InvoiceIssued, ClaimApproved) вытягивают остальной словарь. Избегайте безликих user-updated и status-changed.
🔹 Бросайте вызов расплывчатым словам. "Process", "handle", "manage" – красные флаги. "Система обрабатывает заказ" значит валидирует? маршрутизирует? считает? Термины БД и ORM держите вне домена, за Anti-Corruption Layer.
⚖️ Когда платить налог DDD
Эвристика Kia Raad: если "почему это сложно" – в основном процесс и I/O, налог DDD не платите. Если это бизнес-язык и спорные правила с инвариантами – окупится. Для CRUD и команд без опыта DDD – оверкилл: неверные абстракции хуже их отсутствия.
В 2024 Эванс назвал языковую модель тем же Bounded Context. AI делает перевод быстрым, но любит апгрейдить простые формулировки в "WebSocket real-time synchronization". Дисциплина языка только дорожает.
📚 Что почитать:
"Ubiquitous Language" – Martin Fowler
"Ubiquitous Language and Naming Strategies" – Thurley.dev
