Я хотел бы использовать UML, чтобы нарисовать высокоуровневую диаграмму архитектуры моей системы, управляемой сообщениями.
Я изо всех сил пытаюсь определить правильную схему для рисования системы микросервисов EIP, которые обмениваются сообщениями через каналы сообщений.
Какая диаграмма UML наиболее подходит для этого?
Когда вы говорите EIP, я предполагаю, что вы имеете в виду Шаблоны корпоративной интеграции, т.е. разнообразный набор шаблонов для интеграции корпоративных приложений, таких как Маршрутизатор сообщений, Посредник сообщений, Канал сообщений, Вызов службы и так далее, как описано в нескольких популярных книгах и газетах. Если это так, то ваша ссылка на шаблон Канал сообщений имеет смысл, и я думаю, что понимаю, что вы имеете в виду.
UML — это набор языков общего назначения, который можно использовать для представления многих различных аспектов вашей архитектуры, поэтому ответ на ваш вопрос зависит от того, что вы пытаетесь показать и на каком уровне абстракции. Если вы сосредоточены на обмене сообщениями (время сообщений, порядок и т. д.), вам нужно использовать один из поведенческих языков в UML; если вы хотите представить сообщения (структуру, типы, содержимое и т. д.), вы можете сделать это с помощью структурного языка. Ответ от 8bitjunkie предлагает диаграммы связи для поведенческой стороны, но вы также можете использовать диаграммы последовательности, диаграммы активности и диаграммы состояний в зависимости от вашего внимания / потребностей. Диаграммы последовательности позволяют более четко определить временные аспекты, чем диаграммы связи. Для структуры сообщений я бы рекомендовал диаграммы классов. UML также можно расширить с помощью тегированных значений и стереотипов, чтобы включить гораздо большую специфичность и добавить структурированные детали, если хотите; нет никакого реального ограничения на структурированную информацию, которую вы можете зафиксировать в модели UML.
Из введения enterpriseintegrationpatterns.com:
Профиль UML для EAI [UMLEAI] расширяет семантику диаграмм взаимодействия для описания потоков сообщений между компонентами. Эта нотация очень полезна в качестве точного визуального описания системы, которая может служить основой для генерации кода в рамках архитектуры, управляемой моделями (MDA).
Диаграммы взаимодействия заменены в UML 2 на диаграммы связи.
Однако введение enterpriseintegrationpatterns.com продолжает:
Мы решили не принимать эту нотацию... {потому что} ...профиль UML не охватывает все шаблоны, описанные в нашем языке шаблонов.
На момент написания (апрель 2019 г.) похоже, что в последний раз профиль EAI для UML публиковался март 2004 г.. Это предшествует выдержкам из enterpriseintegrationpatterns.com, который, согласно предыдущей версии, был впервые опубликован в августе 2015 г..
Это говорит о том, что UML 2 плохо подходит для описания системных архитектур, управляемых сообщениями, которые воплощают EIP.
Вы можете использовать диаграмму компонентов и/или диаграмму составной структуры. Если в вашем случае каждый микросервис создается только один раз, вам нужна только одна из этих диаграмм. В противном случае было бы хорошо иметь диаграмму компонентов, показывающую уровень класса, и диаграмму составной структуры, показывающую уровень экземпляра. См. вопрос зависимость диаграммы компонентов от сборки.
Очередь сообщений можно смоделировать как отдельный компонент со стереотипом ‹‹queue>> или как интерфейс со стереотипом ‹‹queue>>. Моделирование очереди как отдельного компонента — лучший выбор, если очередь не принадлежит одной службе. Однако, если он принадлежит (только один сервис ставит/публикует сообщения на нем), то отдельный компонент-очередь загромождает диаграмму и лучше моделировать его как интерфейс, предоставляемый производителем сообщения и требуемый потребителями сообщения. .
