复用的力量：实现企业级能力共享的架构设计

在快速变化的数字时代，企业面临着不断增长的市场需求和日益复杂的技术挑战。如何高效地管理和复用已有的业务能力，成为了企业在数字化转型中不可或缺的一环。本篇文章将以某知名电商平台的订单服务为例，深入探讨企业如何通过微服务架构的实施，实现能力的高效复用。我们将回顾这一转型过程中的关键决策、面临的挑战，以及最终取得的成果，揭示架构变革背后隐藏的战略思维与实践经验。无论你是技术架构师、产品经理，还是对企业数字化转型感兴趣的读者，这篇文章都将为你提供宝贵的见解和启示。

一、复用的基本理解

复用是软件开发中一个重要的概念，能够显著提高开发效率、降低维护成本。在架构设计中实现系统的高可复用性需要考虑多个方面，一般包括技术复用和业务复用。

技术复用包括代码复用和技术组件复用；

业务复用包括业务实体复用、业务流程复用和产品复用。

从复用的程度可以依次划分为产品复用>业务流程复用>业务实体复用>组件复用>代码复用。

复用层次	特点	体会
产品复用	整体性，涉及整个产品或产品的大部分功能模块。高度复用，允许在不同项目中完整地复用整个产品。一致性，保持产品的一致性。	最高级别的复用，适用于公司内部产品线的开发。
		在不同项目中能够保持一致的品质和用户体验。

业务流程复用	通用性，针对通用的业务流程，可在不同项目中被调用。逻辑统一性，提高业务逻辑的一致性。模块化，将常见的业务流程抽象成可独立调用的服务或模块。	提高业务逻辑的一致性和重用性。
		通过模块化设计，降低开发重复业务流程的成本。

业务实体复用	数据模型，关注通用的业务实体，如用户、产品、订单等。一致性，保持数据模型和业务逻辑的一致性。灵活性，在不同业务场景下重复利用通用的业务实体。	通过抽象通用的业务实体，提高数据模型和业务逻辑的一致性。
		在不同业务场景中重复利用通用的业务实体。

组件复用	技术组件，利用现有的技术组件，如开源框架、库、SDK等。加速开发，降低开发成本，提高开发效率。模块化，将通用的功能抽象成可重复使用的组件。	通过使用成熟的技术解决方案，加速项目的开发过程。
		模块化设计，将通用的功能抽象成可重复使用的组件。

代码复用	代码逻辑，将通用的代码逻辑抽取成函数、类或模块。可维护性，提高代码的可维护性和重用性。基础层次，是复用的最基础层次。	最基础的复用层次，提高代码的可维护性和重用性。
		避免在不同部分的项目中重复编写相似的代码。

二、订单服务复用构架举例

（一）基本背景

简易的O2O（Online To Offline，线上到线下）交易业务中，订单的生成渠道主要包括自有小程序/App和外卖平台。用户可以通过小程序或App进行线上下单，也可以通过外卖平台下单，这些线上产生的订单需要被同步到门店的收银系统，以便门店能够进行接单和进一步的处理。具体而言，自有小程序或App过来的订单以及外卖平台过来的订单都需要经过订单服务的处理，确保它们被有效地同步到门店的收银系统中。这个流程的关键步骤包括：

线上下单： 用户通过我们的自有小程序或App完成线上下单，提交订单的详细信息。
外卖平台订单： 可能涵盖多个外卖平台，订单以标准化的方式传递给订单服务。
订单服务处理： 订单服务负责处理这些不同渠道的订单，进行数据标准化和处理，确保它们符合门店收银系统的接口要求。
同步到收银系统： 处理后的订单信息被同步到门店的收银系统中，使门店能够在实体店面及时接单，并进行后续的交易处理。
实时更新： 为了保持订单信息的实时性，订单服务可能会采用异步通信或实时更新机制，确保门店的收银系统能够及时获得最新的订单信息。

通过以上流程能够有效管理线上产生的订单，确保它们能够快速、准确地同步到门店的收银系统，为线下交易提供便利和高效的支持。

（二）一般高复用共享服务的关键

打造可高度复用的共享服务的关键在于清晰的边界划分和内部的抽象设计。

清晰的边界划分

业务场景了解： 在设计共享服务之前，对相关的业务场景进行充分的了解是至关重要的。深入理解业务需求、各方利益相关者的期望以及未来可能的变化，为服务的边界划分提供基础。
划分边界原则： 制定划分边界的原则和做法，确保服务的职责明确，避免后续的争论。明确服务的功能范围，同时清晰说明服务不包括的功能，避免功能模糊和不必要的依赖。
基础服务不主动调用其他服务： 基础服务应该避免主动调用其他服务，以维持服务的独立性和职责的清晰。

内部的抽象设计

数据模型设计： 对服务内部的数据模型进行良好的抽象设计是关键。确保数据模型具有通用性，同时对外提供足够的灵活性以适应不同业务场景。
状态管理通用化： 在处理状态时，提供通用化的方案。可以开放状态定义，允许调用方自定义状态，或者在应用和服务共同管理状态的基础上，抓大放小，通过主状态管理把控核心业务规则。
接口设计规范： 为外部系统提供规范和统一的接口，确保接口名字能够望文生义。提供不同粒度的查询接口，根据返回字段的不同数量，提供粗、中、细粒度的接口，以满足多样化的查询需求。
异步消息通知： 提供异步的消息通知，采用“胖消息”和“瘦消息”的设计，实现订单信息的实时传递，避免服务主动调用外部系统的接口。

（三）明确订单服务的职责和功能-边界问题讨论

订单服务边界划分的核心在于明确服务的职责和功能，确保服务的边界清晰，避免不必要的依赖和职责重叠。

订单服务的核心功能包括

基本信息管理： 管理订单的基础信息，包括下单用户、下单商品、收货人、收货地址、收货时间、堂食或外卖、订单状态、取餐码等。考虑到多个下单渠道，需要定义通用和特定渠道的订单信息。
订单优惠管理： 处理订单的小票信息，包括商品金额、折扣和减免等。这些信息需要展示给用户，也可能用于后续订单成本的分摊。
订单生命周期管理： 管理订单的状态变化，支持通用和可定制的状态定义和状态转换过程。订单服务的状态设计要能够适应不同下单渠道和行业的需求。

订单服务不包括的功能

不主动调用其他服务： 订单服务作为基础服务，不直接调用其他服务。相关信息的整合可以由上层应用调用相关服务实现，或者在基础服务之上创建聚合服务来实现。
不负责和第三方系统的集成： 不处理和第三方系统的同步问题，这些同步功能由额外的同步程序实现，通过调用订单服务或订阅消息通知获取订单信息。
不提供优惠计算或成本分摊逻辑： 不执行具体的优惠计算，只负责存储和查询优惠结果。具体计算和成本分摊由专门的促销系统和财务系统负责。
不提供履单详情和详细物流信息： 不负责存储详细的履单信息和物流信息。订单服务可以存储外部系统的单据号码，但不解释这些信息的含义，留给上层应用或配送系统进行关联和解释。

通过这样的明确划分，订单服务的职责变得清晰，边界明确，有助于团队更好地进行服务内部设计和协作。这种边界划分的方法也可以应用于其他服务的设计过程中。