问题1：在UML用例图中，是否应将内部微服务建模为与用例关联的参与者？ #

绝对不要。UML用例图的核心是展示外部参与者与系统之间的价值交互，参与者的定义是系统边界之外的角色或外部系统（比如你已定义的Guest、Payment Provider）。内部微服务属于系统内部的实现组件，是支撑用例完成的后端逻辑，不属于外部参与者范畴，强行将其加入产品级用例图只会混淆核心价值视角，让图变得冗余且偏离用例图的设计初衷。

问题2：还是应将内部服务保留在系统边界内，若需展示详细交互则为每个微服务创建服务级用例图？ #

这个思路完全正确：

• 产品级用例图只需要聚焦外部参与者的价值需求，内部微服务全部放在系统边界内，作为黑盒实现细节无需暴露。
• 如果需要细化单个微服务的对外能力，可以为每个服务单独创建服务级用例图：此时从该服务的视角出发，其他微服务就变成了外部参与者（比如Auth服务的用例图中，Playback服务就是请求身份校验的外部参与者），这样能清晰展示单个服务对外提供的核心功能，同时避免在产品级图中混入内部实现细节。

问题3：对于服务间关系（Auth ↔ Playback ↔ Catalog…），是否应改用C4（Context/Container/Component）图和序列图，而非强行用例图展示？ #

完全正确，这是更专业的建模分工：

• C4模型：Context图用来展示整个流媒体平台与外部参与者的宏观关系；Container图可以清晰呈现各个微服务（作为独立容器）之间的依赖和协作关系；Component图则深入到单个微服务内部的组件结构。
• 序列图：用来直观展示具体业务流程中，各微服务之间的调用顺序和数据交互（比如用户播放影片时，Playback服务请求Auth校验、再请求Catalog获取影片资源的完整流程）。
  用例图的设计目标是传递用户价值，而非展示内部技术协作，强行用它来表现服务间关系会违背其设计意图，导致图的可读性和专业性下降。

内容的提问来源于stack exchange，提问作者Vu Lam Vic