Ares_ekbmad_nazgulОбычно приходиться строить 3 (три) доменных модели
Это в том случае если в этой области ещё нет стандартных (общих) моделей для обмена сведениями. У каждого участника своя модель. И для каждой пары участников делаются мапинги моделей. Но со временем участники организуются, создают комитет, который отвечает за разработку этой единой модели и совместными усилиями, путем гармонизации множества своих частных моделей создают единую модель.

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

Сумбур.
Сейчас - это делают в рамках DDD и микросервисов на более приземлённом уровне.
Выделяют условные бизнес объекты (считай высокоуровневая модель - которую могут вести просто в Excel/Confluence ).
Часто один бизнес объект = один сервис*.
К примеру условная "банковская карта" - и набор всевозможных операций над ней (не только CRUD, а всё, что нужно бизнесу). Далее все это стекается в общее API - зашел "жмакнул" в карты и сразу все операции (и соответствующий контракт сервиса в том числе для генерации обвязки - нет генератора под ваш язык - не беда, просто используйте http вызовы/запросы), "жмакнул" еще раз и видишь всех подписчиков (потребителей) [зависимости], при желании просмотр цепочек, рядом статистика вызовов, тайминги и соответствующая цена сервиса (в идеале с привязкой к бизнес процессам) - удобно и понятно (всё это уже было в "шинах", но контейнерезация/виртуализация даёт свои плюсы в виде выбора разного стека - хотя на деле это больше минус - выгода копейка, а поддержание это "барахла" $ - но это сродни страховки, так сказать задел на будущее).

Самое сложное тут - выделение тех самых объектов (по факту моделей), как только кол-во полей переваливает за 100-5000-10000, а конкретному потребителю нужно получить несколько "частичек" разных объектов желательно за один запрос - приходит понимание, что работа с жёстко (валидацию никто не отменял) описанным объектом (схемой/моделью) должна быть гибкой (Odata/GraphQL/или просто своя реализация на REST) [испаряются задачи по правки кучи маппингов на интеграции] + "композитники" (эволюционирует в engine/ORM) - всё это уже было - ORMмам и языкам 100 лет в обед - таже Jira имела и имеет поддержку "очеловеченного" JQL (Сейчас + запилили CQL для любителей JSON/REST - опять же "ближе к народу", проще).

Что касается UML - никуда он не делся и отдельные его части прекрасно дополняют текст в ТЗ, а вот для генерации применяется всё реже, т.к. при описании концептуальных моделей в UML можно словить непонимание (тоесть быть "далеко от народа"), куда проще родимый и всем понятный (бизнес) "эксельничек" или страничка в Confluence, для разработчиков xsd=готовые классы через минуту, ну а перевод концептуальной модели из Excel/Confluence пока в ручном режиме или с написанием "наколеночных конвертеров" - т.к. вчера, сегодня xsd, завтра Swagger, вечером graphql/odata ...

Как только появляется "простое" API - тут же возникает магазин по продажи доступа к нему и возникает совершенно иной уровень интеграции и возможностей.