03.应用结构设计

应用结构设计

应用结构描述了应用服务内部的层次结构和组织关系，它决定了系统的模块化程度，以及后续的开发和维护难度。

应用结构的抽象层次

在应用结构设计中，我们通常会把系统抽象为不同的层次。比如，将系统划分为系统级、应用级、模块级和代码级。

这种抽象级别的划分帮助我们在不同层面处理复杂性，确保系统结构清晰且易于维护。如图所示：

• **系统级：**关注的是各个系统的整体布局和治理方式，比如各个系统之间的关系，以及它们如何协同工作。
• **应用级：**聚焦于各个应用的整体架构，包括应用与其他应用的交互方式，以及各个应用在整个系统中的角色。
• **模块级：**对应用内部的进一步细化，它涉及到代码的模块化设计、数据和状态的管理等。通过合理的模块划分，可以提高代码的可维护性、可重用性，减少重复劳动。
• **代码级：**关注的是代码本身的结构和实现方式。这一层级的设计直接影响到代码的质量和实现细节。

抽象级别的存在，主要是为了帮助我们更好地管理系统的复杂性。

1、分解复杂度

如果将所有的细节混杂在一起，整个系统将变得难以理解、维护和扩展。通过设置不同的抽象级别，我们可以将系统的复杂性分解到各个层次，每个层次只需关注特定的功能和职责。

这种分层处理方式使开发人员在专注于系统某一部分时，无需过多关注其他部分的细节，从而大大简化了系统的设计和开发过程。

2、团队协作边界清晰

在大型项目中，通常会有多个团队并行开发。如果系统没有明确的边界，各团队之间很容易产生冲突和重复劳动。

通过清晰的抽象级别划分，不同团队可以专注于系统的不同层次或模块，互不干扰。

3、扩展性强

随着业务需求的变化，系统往往需要不断地扩展和升级。如果系统的架构设计没有合理的抽象级别，扩展和升级就会变得异常困难，甚至可能引发系统的全面重构。

而在有抽象级别的系统中，变更往往只需要聚焦在特定的层次上进行，而不会影响整个系统。例如，一次业务改造只影响模块级别，我们可以在不改变系统整体架构的情况下，替换或新增某个模块，以满足新的业务需求。

应用结构如何划分？

在前文中，我们提到应用服务的设计方法，那么应用服务如何通过一步步转化为代码结构呢？

应用服务会由一系列的应用结构来实现。如图所示。

基于应用服务的划分方案，我们可以进一步细化应用结构，以便更好地组织和管理系统功能。

这个过程涉及多个层次的设计方法：

• 系统和子系统的划分应与业务域和业务子域的粒度保持一致。这有助于我们更好地将业务需求映射到技术实现。
• 一个或多个相关的应用服务可组合成一个可独立部署的应用单元。
• 应用单元内部可进一步分层。例如，参考领域驱动设计（DDD）的分层方法，可分为用户界面层、应用层、领域层和基础设施层。
• 应用单元各层级内部可细分为多个模块，每个模块又包含多个代码单元。

在上述设计方法中，一个应用服务可以单独部署，也可以多个应用服务组合在一起部署。

那应用单元有哪些划分的具体原则呢？应用的划分原则可以参考以下：

1、业务划分原则

最关键的是参考应用服务的划分边界。如果需要提高应用的粒度，可以参考业务域和业务子域的划分。

将相同业务变更因素的功能和数据整合，提升系统内聚性。同时，把不同业务变更因素的功能和数据分开，减少系统耦合度。

2、技术划分原则

在业务初期，尽量从单体应用开始，避免过早划分应用单元，以减少分布式数据库事务和数据不一致的问题。

应用单元内部可进一步分层，避免应用间出现循环依赖或双向依赖，始终保持不同层级间的单向依赖，高层级可以依赖低层级，同层级间不应互相依赖。

仅当真正遇到技术痛点时，例如规模、性能、安全等问题，才考虑拆分应用。如果不拆分会严重影响业务稳定性，则应进行拆分。不要为了拆分而拆分，因为每次拆分都会增加系统复杂度。

示例：订单履约的应用结构划分

如图所示，是订单履约的应用结构划分。

应用层定义软件的应用功能，它负责接收用户请求，协调领域层能力来执行任务，并将结果返回给用户，核心模块包括：

• C端履约服务
  • 预计送达时间：为消费者提供订单的预计处理时间、配送时效等，通常基于订单处理时间、配送情况、配送距离等多种因素计算。
  • 实时订单状态查询：允许消费者实时查看他们的订单所处阶段。包括订单待接单、拣货、打包、已发货、配送中等状态。
  • 配送轨迹跟踪：提供订单从出库到最终送达的完整路径跟踪，消费者可以查看订单的当前位置和过往的配送节点，了解配送进度。
  • 配送信息修改：在订单还未最终发出之前，消费者可能需要更改配送信息，如地址或配送时间。
  • 配送费用明细：显示消费者的订单配送费用的详细分解，包括配送费、包装费、服务费等。
  • 确认收货：消费者可以通过系统确认收货，是完成订单流程的最后一步。
• B端管理模块：
  • 订单派单：接收来自销售平台的订单，并按照既定规则自动分配给对应的门店/仓库。
  • 订单管理：全面管理订单的生命周期，包括订单的确认、处理、状态跟踪、修改和取消等管理操作。
  • 拣货管理：管理仓库内的拣货操作，确保商品被准确无误地从货架上拣选出来，并进行打包和发货。
  • 发货管理：全面管理发货单的生命周期，根据订单的地址、商品大小、重量和客户选择的履约方式，匹配合适的发货方式，并对发货流程进行跟踪。
  • 逆向履约：当客户不满意或需退换商品时，逆向履约模块负责处理退货请求，并管理退货退款和换货流程。

领域层是业务逻辑的核心，专注于表示业务概念、业务状态流转和业务规则，沉淀可复用的服务能力，模块包括：

• 履约服务表达：负责向客户提供履约服务的明确信息。包括预计的送货时间、费用计算、服务选项（如定时达、次日达等）以及履约可达性要求。
• 订单履约调度：提供订单履约调度的核心能力，确保订单被高效地处理和执行。它涉及订单从接收到最终准备配送的所有调度和处理过程，包括订单拆分、分配、拣货、包装、发货等。

订单履约系统与其他系统的依赖关系：

• 商品管理系统：提供的商品信息，包括价格、规格、描述、分类、SKU等。
• 中央库存系统：需要访问中央库存系统来确认下单商品的实物库存情况，包括库存数量和库存位置。
• 配送系统：一旦商品打包完成，将依赖配送系统来处理商品的实际配送工作，包括配送安排、跟踪和状态更新。配送系统提供的配送状态和时间信息，对于订单履约系统中订单状态的更新至关重要。
• 基础数据系统：提供组织机构信息、用户权限信息、服务商信息等基础数据。这些标准化的数据确保各个系统数据的一致性
• 数据分析系统：订单履约系统将产生大量数据，包括订单数据、履约过程数据、配送时效数据等，这些数据需传输到数据分析系统。数据分析系统基于采集到的数据，提供分析与洞察，帮助优化订单履约流程，提升客户满意度，并提供预测分析，来辅助库存管理和需求预测。