小型支付商城系统-MVC工程架构开发

第1-1节 DDD 架构概念

1.DDD 是什么

那 DDD 是什么呢？来自于维基百科的一段定义："Domain-driven design (DDD) is a major software design approach. "，DDD 是一种软件设计方法。也就是说 DDD 是指导我们做软件工程设计的一种手段，它提供了用切割工程模型的各类技巧，如；领域、界限上下文、实体、值对象、聚合、工厂、仓储等。通过 DDD 的指导思想，我们可以在前期投入更多的时间，更加合理的规划出可持续迭代的工程设计。

在 DDD 中有一套共识的工程两阶段设计手段，包括；战略设计、战术设计。

• 战略设计，主要以应对复杂的业务需求，通过抽象、分治的过程，合理的拆分为独立的多个微服务，从而分而治之。与之评价拆分的是否合理，则是在需求开发上线时候，是否每次都大量操作多个微服务开发和上线。这样的战略设计是一种失败的微服务单体设计。所以少数几个中等规模的单体应用，周围环绕着一个服务生态系统，这更有意义。你实际上并没有构建微服务 @贾斯汀·埃瑟里奇

• 战术设计，在这个范畴下，主要以讨论如何基于面向对象思维，运用领域模型来表达业务概念。通常在不做领域模型设计的架构，也就是通常映射到 MVC 三层架构下，Service + 数据模型的开发模式，会让 Service 扁平的、大量的，平铺出非常复杂的业务逻辑代码。再加上行为对象与功能逻辑的分离，贫血模型的开发方式，让行为对象的不断交叉使用，也是让系统不断增加复杂度，并到难以维护的根因。所以这一阶段要设计每一个可以表达领域概念的模型，并运用实体、聚合、领域服务来承载。

2.DDD 的概念

什么是充血模型，领域内都包括什么，实体、聚合、值对象，有什么区别？这样一些"为什么"的概念，也是战术设计过程中非常重要的知识项。搞清楚它们才能做 DDD 设计。

2.1 充血模型

充血模型，指将对象的属性信息与行为逻辑聚合到一个类中，常用的手段如在对象内提供属于当前对象的信息校验、拼装缓存Key、不含服务接口调用的逻辑处理等。

• 这样的方式可以在使用一个对象时，就顺便拿到这个对象的提供的一系列方法信息，所有使用对象的逻辑方法，都不需要自己再次处理同类逻辑。
• 但不要只是把充血模型，仅限于一个类的设计和一个类内的方法设计。充血还可以是整个包结构，一个包下包括了用于实现此包 Service 服务所需的各类零部件（模型、仓储、工厂），也可以被看做充血模型。
• 同时我们还会再一个同类的类下，提供对应的内部类，如用户实名，包括了，通信类、实名卡、银行卡、四要素等。它们都被写进到一个用户类下的内部子类，这样在代码编写中也会清晰的看到子类的所属信息，更容易理解代码逻辑，也便于维护迭代。

2.2 领域模型

领域模型 ，指特定业务领域内，业务规则、策略以及业务流程的抽象和封装。在设计手段上，通过风暴模型 拆分领域模块，形成界限上下文。最大的区别在于把原有的众多 Service + 数据模型的方式，拆分为独立的有边界的领域模块。每个领域内创建自身所属的；领域对象（实体、聚合、值对象）、仓储服务(DAO 操作)、工厂、端口适配器Port（调用外部接口的手段）等。

那么，现在这里有几个概念；领域服务、领域对象、仓储定义、事件消息、端口适配器。我们先来看他们是怎么从贫血模型演变过来的，在细分讲解每个概念。

• 在原本的 Service + 贫血的数据模型开发指导下，Service 串联调用每一个功能模块。这些基础设施（对象、方法、接口）是被相互掉调用的。这也是因为贫血模型并没有面向对象的设计，所有的需求开发只有详细设计。
• 换到充血模型下，现在我们以一个领域功能为聚合，拆分一个领域内所需的 Service 为领域服务，VO、Req、Res 重新设计为领域对象，DAO、Redis 等持久化操作为仓储等。举例；一套账户服务中的，授信认证、开户、提额降额等，每一个都是一个独立的领域，在每个独立的领域内，创建自身领域所需的各项信息。
• 领域模型还有一个特点，它自身只关注业务功能实现，不与外部任何接口和服务直连。如；不会直接调用 DAO 操作库，也不会调用缓存操作 Redis，更不会直接引入 RPC 连接其他微服务。而是通过仓库和端口适配器，定义调用外部数据的含有出入参对象的接口标准，让基础设施层做具体的调用实现。通过这样的方式让领域只关心业务实现，同时做好防腐。

2.3 实体、聚合、值对象

原本在贫血模型下的开发，常常是不会特别在意一个方法的出入参对象的，也经常是很多个服务共用一个VO对象作为入参，只要这个对象能把我需要的属性信息带进来就可以了。

但在 DDD 的领域模型设计下，领域对象的设计是非常面向对象的。而且在整个风暴事件的四色建模过程也是在以领域对象为驱动进行的。

实体、聚合、值对象，三者位于每个领域下的领域对象内，服务于领域内的领域服务。三个对象定义具体如下；

实体

是依托于持久化层数据以领域服务功能目标为指导设计的领域对象。持久化PO对象是原子类对象，不具有业务语义，而实体对象是具有业务语义且有唯一标识的对象，跟随于领域服务方法的全生命周期对象。如；用户PO持久化对象，会涵盖，用户的开户实体、授信实体、额度实体对象。也包括如商品下单时候的购物车实体对象。这个对象也通常是领域服务方法的入参对象。

• 概念：实体 = 唯一标识 + 状态属性 + 行为动作（功能），是DDD中的一个基本构建块，它代表了具有唯一标识的领域对象。实体不仅仅包含数据（状态属性），还包含了相关的行为（功能），并且它的标识在整个生命周期中保持不变。

• 特征：

  • 唯一标识：实体具有一个可以区分其他实体的标识符。这个标识符可以是一个ID、一个复合键或者是一个自然键，关键是它能够唯一地标识实体实例。

  • 领域标识：实体的标识通常来源于业务领域，例如用户ID、订单ID等。这些标识符在业务上有特定的含义，并且在系统中是唯一的。

  • 委派标识：在某些情况下，实体的标识可能是由ORM（对象关系映射）框架自动生成的，如数据库中的自增主键。这种标识符虽然可以唯一标识实体，但它并不直接来源于业务领域。

• 用途：

  • 表达业务概念：实体用于在软件中表达具体的业务概念，如用户、订单、交易等。通过实体的属性和行为，可以描述这些业务对象的特征和能力。

  • 封装业务逻辑：实体不仅仅承载数据，还封装了业务规则和逻辑。这些逻辑包括验证数据的有效性、执行业务规则、计算属性值等。这样做的目的是保证业务逻辑的集中和一致性。

  • 保持数据一致性：实体负责维护自身的状态和数据一致性。它确保自己的属性和关联关系在任何时候都是正确和完整的，从而避免数据的不一致性。

• 实现手段：

  • 定义实体类：在代码中定义一个类，该类包含实体的属性、构造函数、方法等。

  • 实现唯一标识：为实体类提供一个唯一标识的属性，如ID，并确保在实体的生命周期中这个标识保持不变。

  • 封装行为：在实体类中实现业务逻辑的方法，这些方法可以操作实体的状态，并执行相关的业务规则。

  • 使用ORM框架：利用ORM框架将实体映射到数据库表中，这样可以简化数据持久化的操作。

  • 实现领域服务：对于跨实体或跨聚合的操作，可以实现领域服务来处理这些操作，而不是在实体中直接实现。

  • 使用领域事件：当实体的状态发生变化时，可以发布领域事件，这样可以通知其他部分的系统进行相应的处理。

值对象

这个对象在领域服务方法的生命周期过程内是不可变对象，也没有唯一标识。它通常是配合实体对象使用。如为实体对象提供对象属性值的描述，比如；一个公司雇员的级别值对象，一个下单的商品收货的四级地址信息对象。所以在开发值对象的时候，通常不会提供 setter 方法，而是提供构造函数或者 Builder 方法来实例化对象。这个对象通常不会独立作为方法的入参对象，但做可以独立作为出参对象使用。

• 概念：值对象是由一组属性组成的，它们共同描述了一个领域概念。与实体（Entity）不同，值对象不需要有一个唯一的标识符来区分它们。值对象通常是不可变的，这意味着一旦创建，它们的状态就不应该改变。

• 特征：

  • 不可变性（Immutability）：值对象一旦被创建，它的状态就不应该发生变化。这有助于保证领域模型的一致性和线程安全性。

  • 等价性（Equality）：值对象的等价性不是基于身份或引用，而是基于对象的属性值。如果两个值对象的所有属性值都相等，那么这两个对象就被认为是等价的。

  • 替换性（Replaceability）：由于值对象是不可变的，任何需要改变值对象的操作都会导致创建一个新的值对象实例，而不是修改现有的实例。

  • 侧重于描述事物的状态：值对象通常用来描述事物的状态，而不是事物的唯一身份。

  • 可复用性（Reusability）：值对象可以在不同的领域实体或其他值对象中重复使用。

• 用途：

  • 金额和货币（如价格、工资、费用等）

  • 度量和数据（如重量、长度、体积等）

  • 范围或区间（如日期范围、温度区间等）

  • 复杂的数学模型（如坐标、向量等）

  • 任何其他需要封装的属性集合

• 实现手段：

  • 定义不可变类：确保类的所有属性都是私有的，并且只能通过构造函数来设置。

  • 重写equals和hashCode方法：这样可以确保值对象的等价性是基于它们的属性值，而不是对象的引用。

  • 提供只读访问器：只提供获取属性值的方法，不提供修改属性值的方法。

  • 使用工厂方法或构造函数创建实例：这有助于确保值对象的有效性和一致性。

  • 考虑序列化支持：如果值对象需要在网络上传输或存储到数据库中，需要提供序列化和反序列化的支持。

聚合

当你对数据库的操作需要使用到多个实体时，可以创建聚合对象。一个聚合对象，代表着一个数据库事务，具有事务一致性。聚合中的实体可以由聚合提供创建操作，实体也被称为聚合根对象。一个订单的聚合，会涵盖；下单用户实体对象、订单实体、订单明细实体和订单收货四级地址值对象。而那个作为入参的购物车实体对象，已经被转换为实体对象了。------ 聚合内事务一致性，聚合外最终一致性。

• 概念：聚合是领域模型中的一个关键概念，它是一组具有内聚性的相关对象的集合，这些对象一起工作以执行某些业务规则或操作。聚合定义了一组对象的边界，这些对象可以被视为一个单一的单元进行处理。

• 特征：

  • 一致性边界：聚合确保其内部对象的状态变化是一致的。当对聚合内的对象进行操作时，这些操作必须保持聚合内所有对象的一致性。

  • 根实体：每个聚合都有一个根实体（Aggregate Root），它是聚合的入口点。根实体拥有一个全局唯一的标识符，其他对象通过根实体与聚合交互。

  • 事务边界：聚合也定义了事务的边界。在聚合内部，所有的变更操作应该是原子的，即它们要么全部成功，要么全部失败，以此来保证数据的一致性。

• 用途：

1. 封装业务逻辑：聚合通过将相关的对象和操作封装在一起，提供了一个清晰的业务逻辑模型，有助于业务规则的实施和维护。

2. 保证一致性：聚合确保内部状态的一致性，通过定义清晰的边界和规则，聚合可以在内部强制执行业务规则，从而保证数据的一致性。

3. 简化复杂性：聚合通过组织相关的对象，简化了领域模型的复杂性。这有助于开发者更好地理解和扩展系统。

• 实现手段：

  • 定义聚合根：选择合适的聚合根是实现聚合的第一步。聚合根应该是能够代表整个聚合的实体，并且拥有唯一标识。

  • 限制访问路径：只能通过聚合根来修改聚合内的对象，不允许直接修改聚合内部对象的状态，以此来维护边界和一致性。

  • 设计事务策略：在聚合内部实现事务一致性，确保操作要么全部完成，要么全部回滚。对于聚合之间的交互，可以采用领域事件或其他机制来实现最终一致性。

  • 封装业务规则：在聚合内部实现业务规则和逻辑，确保所有的业务操作都遵循这些规则。

• 持久化：聚合根通常与数据持久化层交互，以保存聚合的状态。这通常涉及到对象-关系映射（ORM）或其他数据映射技术。

2.4 仓储和适配器

在 DDD 的设计方法中，领域层做到了只关心领域服务实现。最能体现这样设计的就是仓库和适配器的设计。通常在 Service + 数据模型的设计中，会在 Service 中引入 Redis、RPC、配置中心等各类其他外部服务。但在 DDD 中，通过仓储和适配器以及基础设施层的定义，解耦了这部分内容。

• 特征：

  • 封装持久化操作：Repository负责封装所有与数据源交互的操作，如创建、读取、更新和删除（CRUD）操作。这样，领域层的代码就可以避免直接处理数据库或其他存储机制的复杂性。

  • 领域对象的集合管理：Repository通常被视为领域对象的集合，提供了查询和过滤这些对象的方法，使得领域对象的获取和管理更加方便。

  • 抽象接口：Repository定义了一个与持久化机制无关的接口，这使得领域层的代码可以在不同的持久化机制之间切换，而不需要修改业务逻辑。

• 用途：

  • 数据访问抽象：Repository为领域层提供了一个清晰的数据访问接口，使得领域对象可以专注于业务逻辑的实现，而不是数据访问的细节。

  • 领域对象的查询和管理：Repository使得对领域对象的查询和管理变得更加方便和灵活，支持复杂的查询逻辑。

  • 领域逻辑与数据存储分离：通过Repository模式，领域逻辑与数据存储逻辑分离，提高了领域模型的纯粹性和可测试性。

  • 优化数据访问：Repository实现可以包含数据访问的优化策略，如缓存、批处理操作等，以提高应用程序的性能。

• 实现手段：

  • 定义Repository接口：在领域层定义一个或多个Repository接口，这些接口声明了所需的数据访问方法。

  • 实现Repository接口：在基础设施层或数据访问层实现这些接口，具体实现可能是使用ORM（对象关系映射）框架，如MyBatis、Hibernate等，或者直接使用数据库访问API，如JDBC等。

  • 依赖注入：在应用程序中使用依赖注入（DI）来将具体的Repository实现注入到需要它们的领域服务或应用服务中。这样做可以进一步解耦领域层和数据访问层，同时也便于单元测试。

  • 使用规范模式（Specification Pattern）：有时候，为了构建复杂的查询，可以结合使用规范模式，这是一种允许将业务规则封装为单独的业务逻辑单元的模式，这些单元可以被Repository用来构建查询。

Repository模式是DDD（领域驱动设计）中的一个核心概念，它有助于保持领域模型的聚焦和清晰，同时提供了灵活、可测试和可维护的数据访问策略。

仓储解耦的手段使用了依赖倒置的设计，所有领域需要的外部服务，不在直接引入外部的服务，而是通过定义接口的方式，让基础设施层实现领域层接口（仓储/适配器）的方式来处理。

那么也就是基础设置层负责原则对接数据库、缓存、配置中心、RPC接口、HTTP接口、MQ推送等各项资源，并承接领域服务的接口调用各项服务为领域层提供数据能力。

同时这也会体现出，领域层的实现是具有业务语义的，而到了基础设置层则没有业务语义，都是原子的方法。通过原子方法的组合为领域业务语义提供支撑。

2.5 领域编排

在 DDD 中，每一个领域都是界限上下文拆分的独立结果，而实现业务流程的功能则需要串联各个领域模块提供一整条链路的完整服务。所以也常说领域内事务一致性，领域外最终一致性。

同时这些领域模块因为是独立的，所以也可以被复用。在不同的场景功能诉求下，可以选择不同的领域模块进行组装，这个过程就像搭积木一样。

但这里有一个取舍，如果项目相对来说并不大，也没有太多的编排处理。那么可以直接让触发器层对接领域层，减少编排层后，编码会更加便捷。

2.6 触发器

在所有的模型都定义完成后，领域业务被串联了。那么接下来则是使用，而使用的方式可以包括；接口（http/rpc）、消息监听、定时任务等方式，这些方式统一被定义为触发动作。

由触发发起对编排功能的调用处理。如；定时任务做信贷的计息、开户成功消息通知返利优惠券、提供接口让外部调用授信逻辑等。这些都是触发动作。

第1-2节 DDD 建模方法

四色建模 （风暴事件）是整个 DDD 这套软件设计方法中用于工程拆分界限上下文的非常重要的实践手段。通过建模过程快速识别业务领域中的关键事件和核心流程，也是在这个过程中设计出领域对象的，为后面详细设计和代码开发做指导。

你可以把整个过程理解为，为工程开发提供面向对象设计，涵盖；领域拆分、界限串联、功能聚合。所以相比Service + 数据模型的贫血开发方式，DDD 前期需要付出更多的设计成本，但对于软件的长周期迭代，这样的好处是非常大的。

1.建模目的

工程的建模的目的是为了我们做工程开发时提供指导方案，就像一栋大楼的设计蓝图一样，也像一个超市中会有不同品类的货架，需要提前规划好。所以你需要在工程开发时所需的各类核心内容，都会在建模中体现，如；分几个包、有哪些核心对象、要串联什么流程、有哪些核心业务要实现、过程中与外部服务的交互。

那么为了达成一个讨论的共识，而不是每个人都有一套的标准和词汇。所以会使用 DDD 提供专门的建模方法和名词进行统一的设计，此外因为 DDD 的统一建模语言，不涉及技术编码，也具有通用性，所以可以在建模过程让产品、研发、测试、架构师等人员一起参与讨论。如；领域、领域模型（实体、聚合、值对象）、领域服务、端口适配器、仓储、界限上下文、领域编排等名词。这在上一节已经做了相关的解释。

2.怎么建模

DDD 的建模过程，是以一个用户为起点，通过行为命令，发起行为动作，串联整个业务。而这个用户的起点最初来自于用例图的分析。用例图是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，我们可以分析出所有的行为动作。

在 DDD 中用于完成用户的行为命令和动作分析的过程，是一个四色建模的过程，也称作风暴模型。在使用 DDD 的标准对系统建模前，一堆人要先了解 DDD 的操作手段，这样才能让产品、研发、测试、运营等了解业务的伙伴，都能在同一个语言下完成系统建模。

此图是整个四色建模的指导图，通过寻找领域事件，发起事件命令，完成领域事件的过程，完成 DDD 工程建模。

• 蓝色 - 决策命令，是用户发起的行为动作，如；开始签到、开始抽奖、查看额度等。

• 黄色 - 领域事件，过去时态描述。如；签到完成、抽奖完成、奖品发放完成。它所阐述的都是这个领域要完成的终态。

• 粉色 - 外部系统，如你的系统需要调用外部的接口完成流程。

• 红色 - 业务流程，用于串联决策命令到领域事件，所实现的业务流程。一些简单的场景则直接有决策命令到领域事件就可以了。

• 绿色 - 只读模型，做一些读取数据的动作，没有写库的操作。

• 棕色 - 领域对象，每个决策命令的发起，都是含有一个对应的领域对象。

👩🏻‍🏫敲黑板 综上，左下角的示意图。是一个用户，通过一个策略命令，使用领域对象，通过业务流程，完成2个领域事件，调用1次外部接口个过程。我们在整个 DDD 建模过程中，就是在寻找这些节点。

3.超市举例

我们先通过一个真实场景的案例，代入下 DDD 四色建模的术语，这样可以更有益大家对四色建模理解。这个场景是一个在超市购物的场景。想象下，一个男人，得到了老婆的"命令"，去大超市拿着空的购物车，推进去一圈圈的走，最终完成购物打车回家。

• 脑子中的想法，是媳妇给下达的指令。我们可以理解为决策命令。行为人带着决策命令来到超市。

• 购物车是一种实体，需要填充数据的实体。行为人，带着实体，进入到超市中从各个货架选购商品，装入购物车。选购商品为业务流程，装满的购物车为领域事件。也就是最终态，完成媳妇交代的任务。而手里的烟，则是另外一个领域事件。也就是说，一次的行为动作可以完成多个领域事件。

• 最终购物完成后，打车回家。则是下一个领域流程。通过把从加入出门、做地铁、进超市、采购、打车回家，一整条领域串联起来就是领域编排。

综上，DDD 的领域建模过程，就是一种真实的场景头脑风暴过程，所以可以让更多人同时讨论，拆分出各项领域的边界和领域模型。

4.业务案例

接下来，我们在以一个真实的业务场景来分析系统的四色建模过程。后续我们再以本项目作为建模。这样大家可以有2个例子进行对比，也就可以做自己系统的建模了。

1. 产品诉求

如图，是一个复杂的营销抽奖场景玩法需求，涵盖了；活动配置、签到&奖励、活动账户、抽奖策略「责任链+规则树」、库存扣减、抽奖满N次后阶梯抽奖等。面对这样的复杂系统，非常适合使用 DDD 落地。

分析需求；

1.整体概率相加，总和为1或者分值计算，概率范围千分位

2.抽奖为免费抽奖次数 + 用户消耗个人积分抽奖

3.抽奖活动可给用户分配可抽奖次数，通过点击签到发放

4.活动延伸配置用户库存消耗管理，单独提供表配置各类库存 用户可用总库存、用户可用日库存

5.部分抽奖规则，需要抽奖n次后解锁，才能有机会抽取

6.抽奖完成增加（运气值/积分值/抽奖次数）记录，让用户获得奖品。

7.奖品对接，自身的积分、内部系统的奖品

8.随机积分，发给你积分。

9.黑名单用户抽奖，则给予固定的奖品。

2. 用例图

根据业务需求画系统用例图；

用例图（英语：use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。

用例图，也可以等同于是用户故事（英语：User story）（软件开发和项目管理中的常用术语），主旨是以日常语言或商务用语撰写句子，是一段简单的功能表述。以客户或使用者的观点撰写下有价值的功能、引导、框架来与使用者进行互动，进而推动工作进程。可以被认为是一种规格文件，但更精确而言，它代表客户的需求与方向。以该用户故事来反应对象在组织内的其工作职责、范围、需要进行的任务等。用户故事在敏捷开发方法中用来定义系统需要提供的功能和实现需求管理。

尽管用例本身会涉及大量细节和各种可能性，用例图却能提纲挈领地让人了解系统概况。它为"系统做什么"提供了简化了的图形表示，因此被誉为"搭建系统的蓝图"。

3. 寻找领域事件

接下来，大量的时间，都是在挖掘领域事件。这个过程就是一堆人头脑风暴的过程，避免错失流程节点。

根据产品 PRD 文档，一起开会梳理有哪些领域事件。其实大多数领域事件一个人都可以想到，只是有些部分小的场景和将来可能产生的事件不一定覆盖全。所以要通过产品、测试、以及团队的架构师，一起讨论。

像是整个大营销的抽奖会包括如图所列举的事件。在列举这个阶段，你用在乎格式。也可以是每个人准备好黄色便签纸，想到一个就贴到黑板上一个，只是穷举完成。------ 实际做DDD中，也是这样用便签纸贴黑板，所以用不同的颜色做区分。

4. 识别领域角色和对象

在确定了领域事件以后，接下来要做的就是通过决策命令串联领域事件，并填充上所需要的领域对象。这块的操作，新手可以分开处理，如先给领域事件添加决策命令、执行用户和领域对象，最后在串联流程。就像 事件风暴定义 中的示意一样。

• 首先，通过用户的行为动作，也就是决策命令，串联到对应的领域事件上。并对复杂的流程提供出红色的业务流程。

• 之后，为决策命令添加领域对象，每一个领域在整个流程中都起到了至关重要的作用。

5. 划分领域边界

有了识别出来的领域角色的流程，就可以非常容易的划分出领域边界了。先在事件风暴图上圈出领域边界，之后在单独提供领域划分。

5.1 圈出领域

5.2 领域边界

• 到这步咱们就可以获得整个项目中 DDD 的领域边界划分了。之后再往下就是具体的每个领域对象的详细设计和流程设计。

第1-3节 DDD 工程模型

第2-1节：需求PRD讲解

第2-2节：工程四色建模设计

第2-3节：支付订单场景表设计

第3-1节：MVC 工程框架搭建 基础配置 Git 使用

第3-2节：微信公众号鉴权

❓❓❓问题：没有配置好微信公众号的授权，已申请免费隧道，但是natapp打不开

一、本章诉求

在 mvc 分层框架结构下添加微信公众号鉴权所需的接口，并通过 natapp 内网穿透组件，暴漏本地接口，让微信公众号平台可以配置使用。

在前面章节中已经讲解了，关于微信公众号鉴权的代码实现以及配置使用。所以本节我们会把重点放在 mvc 工程结构的使用，把关于微信的公众号鉴权操作流程按需放到所属模块下。

二、功能分区

mvc 工程结构区内，简单的划分了基础包、数据库、逻辑实现、接口实现。我们在这一节先使用到基础包和提供接口。

• common 承载着对接微信公众号的基础功能。

• web 下的 controller 用于实现对外提供的接口。

三、功能实现

1. yml 配置

# 微信公众号对接
weixin:
  config:
    originalid: gh_e067c267e056
    token: b8b6

• 这里要配置你的 originalid 和 token，也可以默认用 b8b6 我写好的 token。

2. 鉴权接口

package cn.bugstack.controller;

import cn.bugstack.common.MessageTextEntity;
import cn.bugstack.common.SignatureUtil;
import cn.bugstack.common.XmlUtil;
import lombok.extern.slf4j.Slf4j;
import org.apache.commons.lang3.StringUtils;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.*;

/**
 * 微信服务对接，对接地址：<a href="http://xfg-studio.natapp1.cc/api/v1/weixin/portal/receive">/api/v1/weixin/portal/receive</a>
 * <p>
 * http://xfg-studio.natapp1.cc/api/v1/weixin/portal/receive/
 */
@Slf4j
@RestController()
@CrossOrigin("*")
@RequestMapping("/api/v1/weixin/portal/")
public class WeixinPortalController {

    @Value("${weixin.config.originalid}")
    private String originalid;
    @Value("${weixin.config.token}")
    private String token;

    @GetMapping(value = "receive", produces = "text/plain;charset=utf-8")
    public String validate(@RequestParam(value = "signature", required = false) String signature,
                           @RequestParam(value = "timestamp", required = false) String timestamp,
                           @RequestParam(value = "nonce", required = false) String nonce,
                           @RequestParam(value = "echostr", required = false) String echostr) {
        try {
            log.info("微信公众号验签信息开始 [{}, {}, {}, {}]", signature, timestamp, nonce, echostr);
            if (StringUtils.isAnyBlank(signature, timestamp, nonce, echostr)) {
                throw new IllegalArgumentException("请求参数非法，请核实!");
            }
            boolean check = SignatureUtil.check(token, signature, timestamp, nonce);
            log.info("微信公众号验签信息完成 check：{}", check);
            if (!check) {
                return null;
            }
            return echostr;
        } catch (Exception e) {
            log.error("微信公众号验签信息失败 [{}, {}, {}, {}]", signature, timestamp, nonce, echostr, e);
            return null;
        }
    }

    @PostMapping(value = "receive", produces = "application/xml; charset=UTF-8")
    public String post(@RequestBody String requestBody,
                       @RequestParam("signature") String signature,
                       @RequestParam("timestamp") String timestamp,
                       @RequestParam("nonce") String nonce,
                       @RequestParam("openid") String openid,
                       @RequestParam(name = "encrypt_type", required = false) String encType,
                       @RequestParam(name = "msg_signature", required = false) String msgSignature) {
        try {
            log.info("接收微信公众号信息请求{}开始 {}", openid, requestBody);
            // 消息转换
            MessageTextEntity message = XmlUtil.xmlToBean(requestBody, MessageTextEntity.class);
            return buildMessageTextEntity(openid, "你好，" + message.getContent());
        } catch (Exception e) {
            log.error("接收微信公众号信息请求{}失败 {}", openid, requestBody, e);
            return "";
        }
    }

    private String buildMessageTextEntity(String openid, String content) {
        MessageTextEntity res = new MessageTextEntity();
        // 公众号分配的ID
        res.setFromUserName(originalid);
        res.setToUserName(openid);
        res.setCreateTime(String.valueOf(System.currentTimeMillis() / 1000L));
        res.setMsgType("text");
        res.setContent(content);
        return XmlUtil.beanToXml(res);
    }

}

鉴权配置的2个接口，一个是验签，一个是处理接收来自公众号的信息。

3. 对接使用
   

• 首先，要确保 natapp 内网穿透组件开启。

• 之后，要确保 SpringBoot 服务已启动。

4. 通信验证
   

• 发送和接收消息验证。

第3-3节：登录功能设计实现

❓❓❓未测试

一、本章诉求

通过微信公众号平台提供的 API 接口，做微信公众号扫码登录。

扫码登录主要是需要微信公众号平台，提供一个生成带参的二维码，让用户使用微信扫描二维码登录。扫码后我们在微信公众号对接的接口中会接收到扫码完成消息，里面就会含带二维码参数，这样就可以知道到是谁扫描的二维码。我们把扫描后解析的信息和用户做绑定，也就可以完成登录操作了。

第3-4节：商品下单(❗这个功能测试成功)

一、本章诉求

对接数据库表，完成商品下单。

要注意商品下单中，要考虑整个流程中可能存在的失败节点。做编程开发很多时候都是在处理异常。商品下单中，或者下单完成都可能存在失败的情况。比如写库失败，或者调用外部支付平台创建支付单失败，也可能存在用户创建完支付单但未支付的情况。

这些流程都是要在下单中做的处理，在公司的实际场景中，下单还要过很多规则校验。比如账户状态、风控、营销、试算、锁券等等流程，才会到下单。所以很多这样的场景，都会考虑使用设计模式进行解耦，否则很难完成后续的迭代。

第3-5节：对接支付（❓没有成功）

一、本章诉求

通过引入支付宝支付 sdk，实例化支付对象，完成支付对接。并提供商品交易下单和回调接口。

这里要记住一点，所有不是数据库一次事务提交的操作，都没法保证事务一致性。包括；http接口、rpc接口、mq消息等。这些调用过程，都需要有任务作为补偿处理，保证最终一致性。

他们的失败可能是网络超时，导致在调用过程中发生，也可能是消费时发生进行重试。所以这类接口调用除了有任务保持一致性，还有就是要有唯一幂等字段。确保在重复消费的过程中，也只是有一条记录产生或者发生变更。

❓报错（有可能成功了是其他的问题）

第3-6节：支付回调处理(内网穿透没实现❓)

一、本章诉求

对支付流程收尾，完成支付回调、掉单补偿、超时关单的处理，以及监听支付成功消息。

到本节的处理后，我们就把支付流程全部做完了。其实这也是面试中喜欢的问的场景，只有把一个支付的流程，从下单到支付再到回调处理，以及处理各项补偿和监听。面试官才会觉得你是真的对接了支付，而不是在描述一个 CRUD 流程。

第3-7节：前端页面（没实现❓）

一、本章诉求

通过 Docker 给工程配置 Dockerfile、build.sh 文件对项目进行构建和部署，前端应用采用 Nginx 进行部署。

第3-8节：Docker构建和部署（没部署呢❓）

一、本章诉求

通过 Docker 给工程配置 Dockerfile、build.sh 文件对项目进行构建和部署，前端应用采用 Nginx 进行部署。