Ответ
Ubiquitous Language — это строго определённый набор терминов, общий для всех участников проекта (разработчиков, экспертов предметной области, аналитиков), который используется как в обсуждениях, так и в самом коде. Его цель — устранить неоднозначности и потери при переводе бизнес-требований в программную реализацию.
Как это работает на практике:
-
В коде: Имена классов, методов, переменных и модулей напрямую отражают термины предметной области.
// Вместо общего CustomerService с методом process() public class ShoppingCart { private List<CartItem> items; // Термин из домена: "оформить заказ" public Order checkout(PaymentMethod method) { ... } // Термин из домена: "добавить товар" public void addProduct(Product product, Quantity quantity) { ... } } -
В процессе: Если эксперт говорит "заказ подтверждён", в коде появляется метод
Order.confirm(), а неOrder.setStatus(1). Если в процессе обсуждения выясняется, что "корзина" и "черновик заказа" — это разные сущности, это немедленно отражается в модели.
Ключевые преимущества:
- Снижение когнитивной нагрузки: Разработчикам не нужно мысленно переводить "бизнес-слова" в "технические слова".
- Повышение качества дизайна: Модель становится более точным отражением реальных бизнес-процессов.
- Эффективная коммуникация: Обсуждения и документация становятся понятными для всех сторон.
Единый язык не статичен — он развивается вместе с углублением понимания домена и должен быть зафиксирован в глоссарии проекта.
Ответ 18+ 🔞
Слушай, а вот есть такая штука — Ubiquitous Language. По-русски это типа «вездесущий язык», но звучит как диагноз, да? Суть в том, что все на проекте — и программисты, и заказчики, и аналитики — договариваются говорить на одних и тех же терминах. И эти же термины потом лезут прямо в код. Цель — чтобы не было этой пиздецовой игры в испорченный телефон, когда бизнес говорит «подтверди заказ», а в коде у тебя всплывает updateOrderState(OrderStatusEnum.PENDING_VERIFICATION).
Как это выглядит в жизни, ёпта:
-
В коде: Вместо того чтобы выдумывать свои умные технарские названия, ты просто берёшь слова из разговоров с заказчиком и вставляешь их как есть.
// Раньше могло быть: CustomerManager.executeTransaction() // Теперь, бля, так: public class ShoppingCart { // Корзина — так все и называют! private List<CartItem> items; // Элементы корзины — не «юниты», а именно «элементы» // Эксперт сказал: «оформить заказ». Вот тебе и метод: public Order checkout(PaymentMethod method) { ... } // «Добавить товар в корзину» — окей: public void addProduct(Product product, Quantity quantity) { ... } }Видишь? Никакого
process()илиhandle()— сплошная ясность, чувствуешь волнение, ебать? Любой новый разработчик глянет и сразу поймёт, о чём речь. -
В процессе работы: Если в беседе выясняется, что «черновик заказа» и «корзина» — это, оказывается, две большие разницы (одна хуйня хранится день, другая — неделю), то вся команда сразу охуевает дружно, и модель меняется. Не через месяц, а сейчас же. И в коде появляются два разных класса:
CartиOrderDraft. И больше никто не путается.
Что это даёт, кроме чувства глубокого морального удовлетворения:
- Голова не болит. Не надо каждый раз переводить с бизнес-языка на свой птичий технарский. Ты думаешь теми же категориями, что и заказчик. Доверия — ебать ноль к собственным кривым переводам.
- Дизайн становится адекватным. Твоя программа начинает по-настоящему отражать реальные процессы, а не твои фантазии о них. Получается не «программа для базы данных», а «цифровая модель бизнеса».
- Общаться — одно удовольствие. Ты говоришь «давай посмотрим, как работает
checkout», и все — от тестировщицы до директора — понимают, о какой конкретно фиче речь. Никаких «это тот скрин, где три кнопки сверху или тот, где список?».
Главное, чувак, помни: этот язык — не священное писание. Он живой. Сегодня вы договорились, что «клиент» — это кто угодно, а завтра выяснилось, что есть ещё «гость» и «подтверждённый аккаунт». И вы тут же, блядь, обновляете глоссарий и начинаете использовать новые термины. Иначе получится манда с ушами: в документации одно, в коде другое, а в голове у заказчика — третье. И всем будет пиздец.
