小机灵鬼|干货速来！透彻剖析微服务架构设计模式，深入开发Java有奇效( 五 ) 什么是微服务模式随着网络基础设施的高

经过分析最终我们可以得出如下的类图结构
每一个类的作用如下：

Consumer：下订单的用户。 Order：用户下的订单，它用来描述订单并跟踪状态。 OrderLineItem：Order 中的一个条目。 DeliveryInfo：送餐的时间和地址。 Restaurant：为用户准备生产订单的餐馆，同时也要发起送货。 MenuItem：餐馆菜单上的一个条目。 Courier：送餐员负责把订单送到用户手里。可跟踪送餐员的可用性和他们的位置。 Address：Consumer 或 Restaurant 的地址。 Location：Courier 当前的位置，用经纬度表示

定义系统操作当定义了抽象的领域模型之后，接下来就要识别系统必须处理的各种请求。我们并不讨论具体的用户界面，但是你能够想象在每一个用户场景下，前端的用户界面向后端的业务逻辑发出请求，后端的业务逻辑进行数据的获取和处理
识别系统指令的切入点是分析用户故事和场景中的动词。例如 Place Order 用户故事，它非常明确地告诉我们，这个系统必须提供一个 Create Order 操作。很多用户故事都会直接对应或映射为系统命令。表 2-1 列出了一些关键的系统命令

命令规范定义了命令对应的参数、返回值和领域模型类的行为。行为规范中包括前置条件（即当这个操作被调用时必须满足的条件）和后置条件（即这个操作被调用后必须满足的条件）。例如，以下就是 createOrder() 系统操作的规范。

前置条件对应着 Place Order 用户场景中的 givens ，后置条件对应着场景中的Then 。当系统操作被调用时，它会检查前置条件，执行操作来完成和满足后置条件。
抽象的领域模型和系统操作能够回答这个应用“做什么”这一问题。这有助于推动应用程序的架构设计。每一个系统操作的行为都通过领域模型的方式来描述。每一个重要的系统操作都对应着架构层面的一个重大场景，是架构中需要详细描述和特别考虑的地方。现在我们来看看如何定义应用程序的微服务架构
系统操作被定义后，下一步就是完成应用服务的识别。如之前提到的，这并不是一个机械化的流程，相反，有多种拆分策略可供选择。每一种都是从一个侧面来解决问题，并且使用它们独有的一些术语。但是殊途同归，这些策略的结果都是一样的：一个包含若干服务的架构，这样的架构是以业务而不是技术概念为中心
根据业务能力进行服务拆分创建微服务架构的策略之一就是采用业务能力进行服务拆分。业务能力是一个来自于业务架构建模的术语。业务能力是指一些能够为公司（或组织）产生价值的商业活动。特定业务的业务能力取决于这个业务的类型。例如，保险公司业务能力通常包括承保、理赔管理、账务和合规等。在线商店的业务能力包括：订单管理、库存管理和发货组织的业务能力通常是指这个组织的业务是做什么，它们通常都是稳定的。与之相反，组织采用何种方式来实现它的业务能力，是随着时间不断变化的。这个准则在今天尤其明显，很多新技术在被快速采用，商业流程的自动化程度越来越高。例如，不久之前你还通过把支票交给银行柜员的方式来兑现支票，现在很多 ATM 机都支持直接兑现支票，而今，人们甚至可以使用智能手机拍照的方式来兑现支票。正如你所见， “兑现支票”这个业务能力是稳定不变的，但是这个能力的实现方式正在发生戏剧性的变化