我想使用 UML 绘制系统消息驱动架构的高级图。
我正在努力找出正确的图表来绘制一个通过消息通道交换消息的 EIP 微服务系统。
哪个UML图最适合这个？
【问题讨论】：
当您说 EIP 时，我假设您的意思是 企业集成模式，即用于企业应用程序集成的各种模式集合，例如 Message Router、Message Broker、Message Channel、Service Call等等，如几本流行的书籍和论文中所述。如果是这种情况，那么您对 Message Channel 模式的引用是有道理的，我想我理解您的意思。
UML 是一种通用语言集，可用于表示架构的许多不同方面，因此您的问题的答案取决于您试图展示的内容和抽象级别。如果您的重点是messaging（消息定时、排序等），那么您需要使用UML 中的一种behavioural 语言；如果您想表示 消息（结构、类型、内容等），那么您可以使用 structural 语言来实现。 8bitjunkie 的回答建议行为方面的通信图，但您也可以根据您的重点/需要使用序列图、活动图和状态图。序列图允许您比通信图更清楚地识别时序方面。对于消息结构，我建议使用类图。 UML 还可以通过 Tagged Values 和 Stereotypes 进行扩展，以包括更大的特异性并添加结构化细节（如果您愿意）；您可以在 UML 模型中捕获的结构化信息没有真正的限制。
【讨论】：
来自enterpriseintegrationpatterns.com的介绍：
EAI 的 UML 配置文件 [UMLEAI] 丰富了 协作图来描述组件之间的消息流。 这个符号作为一个精确的视觉描述非常有用 作为代码生成的基础的系统 模型驱动架构 (MDA)。
协作图在 UML 2 中被替换为 Communication Diagrams
然而，enterpriseintegrationpatterns.com 的介绍接着说：
我们决定不采用这种表示法... {因为} ...UML Profile 没有捕获我们模式中描述的所有模式 语言。
在撰写本文时（2019 年 4 月），上次发布 UML 的 EAI 配置文件似乎是 March 2004。这早于enterpriseintegrationpatterns.com 的摘录，根据返回机器的方式，该摘录首次发布in August 2015。
这表明 UML 2 无法描述体现 EIP 的消息驱动系统架构。
【讨论】：
您可以使用组件图和/或复合结构图。如果在您的情况下，每个微服务只实例化一次，那么您只需要这些图之一。否则，最好有一个组件图显示类级别和一个复合结构图显示实例级别。见问题Component diagram dependency vs assembly。
可以将消息队列建模为具有构造型> 的单独组件，或者具有构造型> 的接口。如果队列不属于一项服务，则将队列建模为单独的组件是最佳选择。但是，如果它是拥有的（只有一个服务在其上放置/发布消息），那么一个单独的队列组件会使图表变得混乱，最好将其建模为一个接口，由消息生产者提供并由消息消费者要求.
【讨论】：