【问题标题】:How to draw use case diagram based on microservice architecture?如何绘制基于微服务架构的用例图?
【发布时间】:2020-08-25 17:28:34
【问题描述】:

我想开发一个基于微服务架构的Web应用程序,所以,我画了描述系统功能需求的用例图,但我不确定它是否正确?

我的系统有三个微服务。第一个称为“商店服务”,它是负责在线商店发生的所有事情的主要服务:查看产品目录,将产品添加到购物车,填写订单信息。它在我的图表上表示为一个矩形,所有业务流程(功能)都在其中发生。

第二个是银行服务,负责使用客户的银行账户进行付款。

第三个是邮政服务,负责将订单交付给客户以便能够接收。

我有六个演员。我还将它们分为主要和次要的。左边的主要的主动使用系统,而次要的则比较反动。

您会建议我怎样做才能让每个人都更易读和更容易理解我的系统?我应该添加还是删除一些东西?这是我的附图:

对于我在提出当前问题时所犯的所有错误,我深表歉意。对不起,我的英语不好。

【问题讨论】:

    标签: architecture microservices uml use-case


    【解决方案1】:

    除了Log in 看起来还可以。 Log in 不是用例(对参与者没有附加价值),而是附加到某些需要身份验证的 UC 的简单约束。

    为了对您的微服务进行分组,您可以在考虑中引入反映特定微服务的不同系统。然后,与每个微服务相关的用例将出现在反映特定微服务的边界内。

    进一步通知:仅附属于次要参与者的 UC(出现在右侧)我认为它们不是 UC,而只是包括 UC 在内的事件流。 UC 旨在展示所考虑的系统为其主要参与者带来的附加值。你这样做的方式只是功能分解。这不是 UC 的全部意义所在。

    我一如既往地建议阅读 Bittner/Spence 关于用例的信息。

    【讨论】:

    • 非常清楚,有很好的建议,像往常一样!然而,我想知道按微服务分解需求是否是一个好主意,因为微服务的拆分更多是关于解决方案和解决方案空间的内部,而不是外部世界和参与者观察到的需求和问题空间(此外,外部世界可能会通过一个 API 网关,该网关会隐藏有关哪个服务正在做什么的详细信息。
    • @qwerty_so,谢谢你的回答。据我所知,我应该排除图表上的次要演员,不是吗?
    • @Christophe 我将微服务视为子域。由于它是“微观”的,问题可能是这是否有意义,因为子域通常将复杂的结构分解为可管理的结构。这可能更像是一个架构问题。
    • @Vladislav 否。您应该删除“付款”气泡并将“银行服务”直接与“订购”连接。如果“付款”是一个独立的 UC,您应该将其与主要参与者联系起来。但如果没有,请删除它。
    • @qwerty_so 好的,如果“按子域服务”的架构模式已经确定,并且不包括替代分解策略,这确实是相关的(参见分解项下的microservices.io/patterns/index.html
    猜你喜欢
    • 2021-09-04
    • 2020-07-22
    • 1970-01-01
    • 1970-01-01
    • 2017-10-15
    • 2018-03-29
    • 1970-01-01
    • 2018-04-07
    • 2014-01-08
    相关资源
    最近更新 更多