Разумеется, необходимо различать прикладные сервисы, вроде «Уведомлений», «Идентификации» и доменно-специфичные микросервисы. Например, сервис «Уведомлений» может использоваться множеством других сервисов, но при этом ничего не будет знать о доменной специфике сервисов, использующих его. Но представим, что наш сервис уведомлений изначально был разработан в домене «Кредитования» под собственные задачи. Он знает, что такое «Уведомление о просроченном платеже», что такое «Уведомение о следующем платеже». И вот мы решили его заиспользовать еще и для домена страхования, дополнив событиями «Уведомение о страховом случае», «Уведомлении о необходимости продлить страховой контракт». Тем самым была создана сильная зависимость между доменами Страхования и Кредитования и теперь изменения, вносимые одним из доменов в сервис «Уведомлений» потребуют координаци с другим доменом. Этот сервис более не является микросервисом, так как его граница не проходит по границе бизнес-домена, он совмещает в себе ответственности двух различных доменов. Вариантов здесь может быть два: 1. Выделить наравне с доменами «Кредитование» и «Страхование» домен «Уведомления», в домен «Уведомления» войдет только специфичная для этого домена функциональность и никаких знаний о кредитовании или страховании. 2. Развернуть в домене «Страхование» собственный сервис «Уведомлений», который будет знать только об специфичных для страхования уведомлениях. И то и другое – повторное использование, но без создания сложных, блокирующих зависимостей и без появления дополнительной координационной нагрузки.