电子商务网站可能会将复杂的注册流程以微服务的形式开发。这个微服务会调用诸如用户信息、欢迎通知和特殊优惠等不同的服务。功能并不明确属于特定领域，或者需要和多个业务领域交互；所要实现的用例非常复杂，将其放到其他服务中会违背单一职责的原则。
服务划分方式可以识别应用中的“名词”，面向业务领域中已有的对象和事物。还可以识别应用中的“动词”或者用例，然后开发与这些职责对应的服务。我们尝试识别应用中的“动词”并应用到SimpleBank公司应用中，了解它与面向“名词”的拆分方式的区别。
示例：按照投资策略下单
客户可以将他的钱投入某个投资策略中，这样系统就会生成相应的订单，比如，如果客户投入1000美元，而这个策略指定了20%的资金要投到ABC股票，那么就会生成一个购买200美元ABC股票的订单。
这就引出了如下几个问题。
（1）假设客户通过信用卡或者银行转账这样的外部支付方式来进行投资的，如何接收这笔投资资金呢？
（2）哪个服务负责按照策略来创建订单呢？它与已有的order服务和investment strategy服务的关系如何呢？
（3）如何跟踪这些按照策略创建的订单呢？
我们可以把这个功能放到已有的investment strategy服务中开发。但是下单的动作会不必要地扩大这个服务所包含的职责范围。同样，将这个功能放到order服务中也不合理。将所有可能的订单来源都合并到一个服务中会导致这个服务频繁地因为各种原因而被修改。
我们可以以这个用例为起点初步制订一个独立的服务——将其称为PlaceStrategyOrder服务，大致描述了这个服务所要执行的流程。
考虑一下这个服务的输入。为了完成下单操作，这个服务需要3样东西：要下单的账号、所使用的策略以及投资的金额。
如果所支付的资金来自于外部系统，那我们就必须等到这笔钱到账以后才能发布订单。然而，由PlaceStrategyOrders服务来处理资金的收取是不合理的。显然，这是一种截然不同的业务能力。反之，我们可以将策略订单与支付记录相关联起来。
这预示了一个新的服务功能的存在：支付（payment）。这一功能要支持：初始化用户的支付款项、处理与第三方支付系统交互的款项以及更新SimpleBank中的账户信息。
众所周知，支付并不是即时到账的，所以我们可以预料到这个payment服务会触发像PaymentCompleted这样的异步事件来供其他服务监听。
从PlaceStrategyOrder服务的角度看，如何实现这个支付功能是不重要的，只要实现了消费方要求的接口就可以。可以通过一个单独的payment服务来实现，也可以用一组面向操作的服务（如CompleteBankTransfer）来实现。
利用PlaceStrategyOrder服务进行支付和投资的流程
这张图缺少了将订单提交到市场的那部分。尽管这个PlaceStrategyOrder服务会创建订单，但是这个功能显然不属于已有的order服务。order服务会把提交订单到市场功能开放出来供其他不同的消费者使用，其中也包括这个新开发的PlaceStrategyOrder服务；尽管订单的来源各不相同，但是将它们提交到市场的流程还是一致的。
最后，我们将订单与创建这些订单的策略以及投资记录的联系持久化保存下来。
上图所示，PlaceStrategyOrder服务会负责存储它收到的任何请求——显然，它明确拥有这些数据。因此，在PlaceStrategyOrder服务中将订单ID记录下来以保留外键关联。也可以将订单的源ID——这个投资策略的投资请求ID保存到订单服务中，尽管看起来不大可能需要从这个方向来进行查询。
order服务在订单完成后发OrderCompleted事件消息，而PlaceStrategyOrder服务会监听这些事件来更新整个投资请求的状态。
加上order服务，PlaceStrategyOrder服务根据投资策略创建订单的完整流程，如图所示
太棒了！我们现在又设计了一个新服务。不同于前面章节的内容，我们设计的这个服务准确体现了一个具体的复杂用例，而非泛泛的功能。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论