定义其架构的第一步是将应用程序的需求提炼为各种关键请求 。 但是 ， 不是根据特定的进程间通信技术（如 REST 或消息）来描述这些请求 ， 而是使用更抽象的系统操作这个概念 。 系统操作（system operation）是应用程序必须处理的请求的一种抽象描述 。 它既可以是更新数据的命令 ， 也可以是检索数据的查询 。 每个命令的行为都是根据抽象领域模型定义的 ， 抽象领域模型也是从需求中派生出来的 。 系统操作是描述服务之间协作方式的架构场景
该流程的第二步是确定如何分解服务 。 有几种策略可供选择 。 一种源于业务架构学派的策略是定义与业务能力相对应的服务 。 另一种策略是围绕领域驱动设计的子域来分解和设计服务 。 但这些策略的最终结果都是围绕业务概念而非技术概念分解和设计的服务 。
定义应用程序架构的第三步是确定每个服务的 API 。 为此 ， 你将第一步中标识的每个系统操作分配给服务 。 服务可以完全独立地实现操作 。 或者 ， 它可能需要与其他服务协作 。 在这种情况下 ， 你可以确定服务的协作方式 ， 这通常需要服务来支持其他操作
识别系统操作定义应用程序架构的第一步是定义系统操作 。 起点是应用程序的需求 ， 包括用户故事及其相关的用户场景（请注意 ， 这些与架构场景不同） 。 使用图 2-6 中所示的两步式流程识别和定义系统操作 。 第一步创建由关键类组成的抽象领域模型 ， 这些关键类提供用于描述系统操作的词汇表 。 第二步确定系统操作 ， 并根据领域模型描述每个系统操作的行为 。
创建抽象领域模型定义系统操作的第一步是为这个应用程序描绘一个抽象的领域模型 。 注意这个模型比我们最终要实现的简单很多 。 应用程序本身并不需要一个领域模型 ， 因为我们在稍后会学到 ， 每一个服务都有它自己的领域模型 。 尽管非常简单 ， 抽象的领域模型仍旧有助于在开始阶段提供帮助 ， 因为它定义了描述系统操作行为的一些词语创建领域模型会采用一些标准的技术 ， 例如通过与领域专家沟通后 ， 分析用户故事和场景中频繁出现的名词 。 例如 Place Order 用户故事 ， 我们可以把它分解为多个用户场景 ，
Given a consumerAnd a restaurantAnd a delivery address/time that can be served by that restaurantAnd an order total that meets the restaurant's order minimumWhen the consumer places an order for the restaurantThen consumer's credit card is authorizedAnd an order is created in the PENDING_ACCEPTANCE stateAnd the order is associated with the consumerAnd the order is associated with the restaurant在这个用户场景中的名词 ， 如 Consumer、Order、Restaurant 和 CreditCard ， 暗示了这些类都是需要的
同样 ， Accept Order 用户故事也可以分解为多个场景 ， 如下
Given an order that is in the PENDING_ACCEPTANCE stateand a courier that is available to deliver the orderWhen a restaurant accepts an order with a promise to prepare by a particulartimeThen the state of the order is changed to ACCEPTEDAnd the order's promiseByTime is updated to the promised timeAnd the courier is assigned to deliver the order