干货速来！透彻剖析微服务架构设计模式，深入开发Java有奇效

如何定义一个微服务架构呢？跟所有的软件开发过程一样，一开始我们需要拿到领域专家或者现有应用的需求文档。跟所有的软件开发一样，定义架构也是一项艺术而非技术。本节我们将介绍一种定义应用程序架构的三步式流程

定义其架构的第一步是将应用程序的需求提炼为各种关键请求。但是，不是根据特定的进程间通信技术（如 REST 或消息）来描述这些请求，而是使用更抽象的系统操作这个概念。系统操作（system operation）是应用程序必须处理的请求的一种抽象描述。它既可以是更新数据的命令，也可以是检索数据的查询。每个命令的行为都是根据抽象领域模型定义的，抽象领域模型也是从需求中派生出来的。系统操作是描述服务之间协作方式的架构场景

该流程的第二步是确定如何分解服务。有几种策略可供选择。一种源于业务架构学派的策略是定义与业务能力相对应的服务。另一种策略是围绕领域驱动设计的子域来分解和设计服务。但这些策略的最终结果都是围绕业务概念而非技术概念分解和设计的服务。

定义应用程序架构的第三步是确定每个服务的 API。为此，你将第一步中标识的每个系统操作分配给服务。服务可以完全独立地实现操作。或者，它可能需要与其他服务协作。在这种情况下，你可以确定服务的协作方式，这通常需要服务来支持其他操作

识别系统操作

==========

定义应用程序架构的第一步是定义系统操作。起点是应用程序的需求，包括用户故事及其相关的用户场景（请注意，这些与架构场景不同）。使用图 2-6 中所示的两步式流程识别和定义系统操作。第一步创建由关键类组成的抽象领域模型，这些关键类提供用于描述系统操作的词汇表。第二步确定系统操作，并根据领域模型描述每个系统操作的行为。

创建抽象领域模型

========

定义系统操作的第一步是为这个应用程序描绘一个抽象的领域模型。注意这个模型比我们最终要实现的简单很多。应用程序本身并不需要一个领域模型，因为我们在稍后会学到，每一个服务都有它自己的领域模型。尽管非常简单，抽象的领域模型仍旧有助于在开始阶段提供帮助，因为它定义了描述系统操作行为的一些词语

创建领域模型会采用一些标准的技术，例如通过与领域专家沟通后，分析用户故事和场景中频繁出现的名词。例如 Place Order 用户故事，我们可以把它分解为多个用户场景，

Given a consumer

And a restaurantAnd a delivery address/time that can be served by that restaurantAnd an order total that meets the restaurant’s order minimum

When the consumer places an order for the restaurant

Then consumer’s credit card is authorized

And an order is created in the PENDING_ACCEPTANCE state

And the order is associated with the consumer

And the order is associated with the restaurant

在这个用户场景中的名词，如 Consumer、Order、Restaurant 和 CreditCard，暗示了这些类都是需要的

同样，Accept Order 用户故事也可以分解为多个场景，如下

Given an order that is in the PENDING_ACCEPTANCE state

and a courier that is available to deliver the orderWhen a restaurant accepts an order with a promise to prepare by a particular

timeThen the state of the order is changed to ACCEPTED

And the order’s promiseByTime is updated to the promised time

And the courier is assigned to deliver the order

经过分析最终我们可以得出如下的类图结构

每一个类的作用如下：

• 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 机都支持直接兑现支票，而今，人们甚至可以使用智能手机拍照的方式来兑现支票。正如你所见，“兑现支票”这个业务能力是稳定不变的，但是这个能力的实现方式正在发生戏剧性的变化

从业务能力到服务

============

一旦确定了业务能力，就可以为每个能力或相关能力组定义服务。下图显示了 FTGO应用程序从能力到服务的映射。某些顶级能力（如会计记账能力）将映射到服务。在其他情况下，子能力映射到服务

上图显示的服务仅仅是定义架构的第一次尝试。随着我们对应用程序领域的了解越来越多，它们可能会随着时间的推移而变化，特别是架构定义流程中的一个重要步骤是调查服务如何在每个关键架构服务中协作。例如，你可能会发现由于过多的进程间通信而导致特定的分解效率低下，导致你必须把一些服务组合在一起。相反，服务可能会在复杂性方面增长到值得将其拆分为多个服务的程度

根据子域进行服务拆分

==============

领域驱动设计是构建复杂软件的方法论，这些软件通常都以面向对象和领域模型为核心。领域模型以解决具体问题的方式包含了一个领域内的知识。它定义了当前领域相关团队的词汇表，DDD 也称之为通用语言（Ubiquitous language）。领域模型会被紧密地映射到应用的设计和实现环节。在微服务架构的设计层面，DDD 有两个特别重要的概念，子域和限界上下文

领域驱动为每一个子域定义单独的领域模型。子域是领域的一部分，领域是 DDD 中用来描述应用程序问题域的一个术语。识别子域的方式跟识别业务能力一样：分析业务并识别业务的不同专业领域，分析产出的子域定义结果也会跟业务能力非常接近。FTGO 的子域包括：订单获取、订单管理、餐馆管理、送餐和会计。正如你所见：这些子域跟我们之前定义的业务能力非常接近。

DDD 把领域模型的边界称为限界上下文（bounded context）。限界上下文包括实现这个模型的代码集合。当使用微服务架构时，每一个限界上下文对应一个或者一组服务。换一种说法，我们可以通过 DDD 的方式定义子域，并把子域对应为每一个服务，这样就完成了微服务架构的设计工作。图 2-9 展示了子域和服务之间的映射，每一个子域都有属于它们自己的领域模型。

DDD 和微服务架构简直就是天生一对。DDD 的子域和限界上下文的概念，可以很好地跟微服务架构中的服务进行匹配。而且，微服务架构中的自治化团队负责服务开发的概念，也跟 DDD 中每个领域模型都由一个独立团队负责开发的概念吻合。更有趣的是，子域用于它自己的领域模型这个概念，为消除上帝类和优化服务拆分提供了好办法

上帝类的处理

======

上帝类是在整个应用程序中使用的全局类。上帝类通常为应用程序的许多不同方面实现业务逻辑。它有大量字段映射到具有许多列的数据库表。大多数应用程序至少有一个这样的上帝类。Order 类是 FTGO 应用程序中上帝类的一个很好的例子。这并不奇怪：毕竟 FTGO 的

目的是向客户提供食品订单。系统的大多数部分都涉及订单。如果 FTGO 应用程序具有单个领域模型，则 Order 类将是一个非常大的类。它将具有与应用程序的许多不同部分相对应的状态和行为。下图显示了使用传统建模技术创建的 Order 类的结构

Order 类具有与订单处理、餐馆订单管理、送餐和付款相对应的字段及方法。由于一个模型必须描述来自应用程序的不同部分的状态转换，因此该类还具有复杂的状态模型。在目前情况下，这个类的存在使得将代码分割成服务变得极其困难

一种解决方案是将 Order 类打包到库中并创建一个中央 Order 数据库。处理订单的所有服务都使用此库并访问访问数据库。这种方法的问题在于它违反了微服务架构的一个关键原则，并导致我们特别不愿意看到的紧耦合。例如，对 Order 模式的任何更改都要求其他开发团队同步更新和重新编译他们的代码。

另一种解决方案是将 Order 数据库封装在 Order Service 中，该服务由其他服务调用以检索和更新订单。该设计的问题在于这样的一个 Order Service 将成为一个纯数据服务，成为包含很少或没有业务逻辑的贫血领域模型（anemic domain model）。这两种解决方案都没有吸引力，但幸运的是，DDD 提供了一个好的解决方案。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

710927206577)]
[外链图片转存中…(img-d8JGVfqS-1710927206578)]
[外链图片转存中…(img-anwqIrnd-1710927206578)]

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
[外链图片转存中…(img-dJZzPhav-1710927206579)]