前置条件和后置条件对应着之前用户场景中的描述。
多数与系统操作相关的架构元素是命令。查询虽然仅仅是简单地获取数据，但是也同样重要。
应用程序除了实现指令以外，也必须实现查询。查询为用户决策提供了用户界面。在目前阶段，我们并没有开始为FTGO应用程序构思任何用户界面，但是需要注意，当消费者下订单时往往是如下所示的过程。
1.用户输入送餐地址和期望的送餐时间；
2.系统显示当前可用的餐馆；
3.用户选择餐馆；
4.系统显示餐馆的菜单；
5.用户点餐并结账；
6.系统创建订单。
这个用户场景包含了以下的查询型操作：
findAvailableRestaurants(deliveryAddress,deliveryTime)：获取所有能够送餐到用户地址并满足送餐时间要求的餐馆。
findRestaurantMenu(id)：返回餐馆信息和这家餐馆的菜单项。
在这两项查询中，findAvailableRestaurants()也许是在架构层面尤其重要的一个。它是一个包含了地理位置等信息的复杂查询。地理查询的组件负责找到送餐地址周围所有满足要求的餐馆位置。同时它也需要过滤那些在订单准备和送餐时间范围内没有营业的餐馆。另外，这个查询的性能尤其重要，因为执行这个查询时，客户多数都是“在线急等”的状态，耽误不得。
抽象的领域模型和系统操作能够回答这个应用“做什么”这一问题。这有助于推动应用程序的架构设计。每一个系统操作的行为都通过领域模型的方式来描述。每一个重要的系统操作都对应着架构层面的一个重大场景，是架构中需要详细描述和特别考虑的地方。现在我们来看看如何定义应用程序的微服务架构。
系统操作被定义后，下一步就是完成应用服务的识别。如之前提到的，这并不是一个机械化的流程，相反，有多种拆分策略可供选择。每一种都是从一个侧面来解决问题，并且使用它们独有的一些术语。但是殊途同归，这些策略的结果都是一样的：一个包含若干服务的架构，这样的架构是以业务而不是技术概念为中心。
我们先来看看第一个策略：使用业务能力来定义服务。
2. 根据业务能力进行服务拆分
创建微服务架构的策略之一就是采用业务能力进行服务拆分。业务能力是一个来自于业务架构建模的术语。业务能力是指一些能够为公司（或组织）产生价值的商业活动。特定业务的业务能力取决于这个业务的类型。例如，保险公司业务能力通常包括承保、理赔管理、账务和合规等。在线商店的业务能力包括：订单管理、库存管理和发货，等等。
模式：根据业务能力进行服务拆分
业务能力定义了一个组织的工作
组织的业务能力通常是指这个组织的业务是做什么，它们通常都是稳定的。与之相反，组织采用何种方式来实现它的业务能力，是随着时间不断变化的。这个准则在今天尤其明显，很多新技术在被快速采用，商业流程的自动化程度越来越高。例如，不久之前你还通过把支票交给银行柜员的方式来兑现支票，现在很多ATM机都支持直接兑现支票，而今，人们甚至可以使用智能手机拍照的方式来兑现支票。正如你所见，“兑现支票”这个业务能力是稳定不变的，但是这个能力的实现方式正在发生戏剧性的变化。
识别业务能力
一个组织有哪些业务能力，是通过对组织的目标、结构和商业流程的分析得来的。每一个业务能力都可以被认为是一个服务，除非它是面向业务的而非面向技术的。业务能力规范包含多项元素，比如输入和输出、服务等级协议（SLA）。例如，保险承保能力的输入来自客户的应用程序，这个业务能力的输出是完成核保并报价。
业务能力通常集中在特定的业务对象上。例如，理赔业务对象是理赔管理功能的重点。能力通常可以分解为子能力。例如，理赔管理能力具有多个子能力，包括理赔信息管理、理赔审核和理赔付款管理。
把FTGO的业务能力逐一列出来似乎也并不太困难，如下所示。
- 供应商管理。
Courier management：送餐员相关信息管理；
Restaurantinformation management：餐馆菜单和其他信息管理，例如营业地址和时间。
- 消费者管理：消费者有关信息的管理。
- 订单获取和履行。
Order management：让消费者可以创建和管理订单。
Restaurant ordermanagement：让餐馆可以管理订单的生产过程。
送餐。
Courieravailability management：管理送餐员的实时状态。
Deliverymanagement：把订单送到用户手中。
- 会计记账。
Consumeraccounting：管理跟消费者相关的会计记账。
Restaurantaccounting：管理跟餐馆相关的会计记账。
Courieraccounting：管理跟送餐员相关的会计记账。
其他。
顶级能力包括供应商管理、消费者管理、订单获取和履行以及会计记账。可能还有许多其他顶级能力，包括与营销相关的能力。大多数顶级能力都会分解为子能力。例如，订单获取和履行被分解为五个子能力。
这个能力层次的有趣方面是有三个餐馆相关的能力：餐馆信息管理、餐馆订单管理和餐馆会计记账。那是因为它们代表了餐馆运营的三个截然不同的方面。
接下来，我们将了解如何使用业务能力来定义服务。
从业务能力到服务
一旦确定了业务能力，就可以为每个能力或相关能力组定义服务。图4显示了FTGO应用程序从能力到服务的映射。某些顶级能力（如会计记账能力）将映射到服务。在其他情况下，子能力映射到服务。
图4 将FTGO业务能力映射到服务。能力层次结构各个级别的能力都映射到服务
决定将哪个级别的能力层次结构映射到服务是一个非常主观的判断。我对这种特定映射的理由如下：
- 我将供应商管理的子能力映射到两种服务，因为餐馆和送餐员是非常不同类型的供应商。
- 我将订单获取和履行能力映射到三个服务，每个服务负责流程的不同阶段。我将送餐员可用性管理（Courier availability management）和交付管理（Deliverymanagement）能力结合起来，并将它们映射到单个服务，因为它们交织在一起。
- 我将会计记账能力映射到自己的独立服务，因为不同类型的会计记账看起来很相似。
之后将针对餐馆和送餐员的费用支付和针对消费者的订单收款分开是有意义的。
围绕能力组织服务的一个关键好处是，因为它们是稳定的，所以最终的架构也将相对稳定。架构的各个组件可能会随着业务的具体实现方式的变化而发展，但架构仍保持不变。
话虽如此，重要的是要记住图4中显示的服务仅仅是定义架构的第一次尝试。随着我们对应用程序领域的了解越来越多，它们可能会随着时间的推移而变化，特别是架构定义流程中的一个重要步骤是调查服务如何在每个关键架构服务中协作。例如，你可能会发现由于过多的进程间通信而导致特定的分解效率低下，导致你必须把一些服务组合在一起。相反，服务可能会在复杂性方面增长到值得将其拆分为多个服务的程度。此外，在第5节中将描述可能导致你重新审视当前分解决策的几个障碍。
下一篇我们来看看基于领域驱动设计分解应用程序的方法。
