Провёл ретроспективу своего рабочего опыта в продуктах, где бизнес-модель превышает уровень многостраничника и обнаружил, насколько сильное влияние начинает оказывать соблюдение командой единого языка предметной области (тема DDD) на общую атмосферу продукта. Влияние может быть как в положительную, так и в отрицательную сторону. Оно может дать о себе знать на уровне кода, на уровне общения внутри одной команды, на уровне общения между разными командами и целыми отделами. Для себя считаю нужным ловить такие моменты за руку и обсуждать их на месте, ведь "чем выше шкаф, тем громче он падает".

Делюсь некоторыми своими кейсами в ознакомительных целях, где можно наглядно увидеть "баги" единого языка

1. Альфа Банк, игровая экосистема. Поступила задача: надо было взять уникальный промокод игрока и вшивать его в ccылки, которые этот игрок будет пересылать своим друзьям. Звучит, как задача на полчаса - час

Начались поиски промокода. Подёргал команду, внятного ответа не услышал, получил лишь доку от альфы, где как раз употреблялся термин "промокод"

Начал думать, где брать этот промокод. Прочекал урл адрес, где он должен приходить. Его я не нашёл, но нашёл параметр user_id=тут_айдишник_юзера. Мне тогда показалось странным, что по логике этой задачи, надо бы взять айдишник игрока и вставить в ссылку. Тогда в ссылке будет зашит этот айдишник, и если друг перейдет по этой ссылке, то владельцу ссылки можно будет накидать бонусов за привлечение друга. Но мне-то сказали промокод вставить, а не айдишник) Временно забил на эту таску и приступил к другой

Через пару дней попросил уточнить у клиента, как выглядит этот промокод, а то я в ступоре уже. Не помню точную структуру, но промокод выглядел точно так же, как и айди игрока. И да, промокод - это и есть айди игрока)))

Что в сухом остатке, если опустить слово "промокод": необходимо из урла выцепить айди игрока и вставить в реферальную ссылку, как я и предположил, но львиную долю времени потратил на выяснение того, что такое промокод. Конец истории)

2. Проект по заработку водителей в Яндекс.Такси. Задача: необходимо отрисовать список пользователей, которые уже есть в яндексе, но пока отсутствуют в нашей диспетчерской, их нужно показывать админу.

В проекте есть две административные роли: админ и оунер. Оунер имеет всё то же самое, что и админ, только ещё больше полномочий. Иными словами - суперюзер. Здесь подчеркну, что это две разные роли, и бизнес-смысл у них разный, поэтому админ - не равно оунер.

Проверил список неприкреплённых водителей со стороны админа - всё good. Проверил со стороны оунера - странно, запрос тоже проходит успешно. Но ведь в задаче было сказано, что водители должны быть видны только админу, так? А у нас их и оунер может смотреть. И тут как в первом кейсе с промокодами. По смыслу-то всё окей, оунеру как будто тоже можно смотреть неприкреплённых водителей. Однако в задаче говорится про админа, и тут опять вопросики возникают

Сообщил бэку, что неприкрепленных водителей можно получать, будучи оунером, на что получил ответ, что всё окей. Я: ну ведь мы должны иметь к ним доступ только под админом. Бэк: ну они же по сути оба админы. Я: ну в задаче-то говорится про роль админа, а для меня админ и оунер - разные роли с точки зрения бизнеса)

Итого: подсветил несколько кейсов из практики, где проблемы с единым языком фоном витают в воздухе и могут не слабо так отнять время на понимание сути вопроса. Для себя всегда держу в голове ловушку с единым языком и считаю важным в новых задачах/проектах подмечать в первую очередь бизнес-терминологию в команде, подсвечивать для себя несостыковки в терминах/логике и не стесняться уточнять, уточнять и ещё раз уточнять. Иначе будем каждый раз заниматься поиском промокода для игрока ))