企业架构，也叫4A 架构，包括业务架构(Business Architecture)，信息架构(Information Architecture)、应用架构(Application Architecture)和技术架构(Technology Architecture)的一体化设计，是企业数字化转型项目实施信息系统整体设计的通用方法。

参考：企业架构框架：四横五纵!

本4A 架构一体化设计方法结合了业界大厂的企业架构方法、DDD 领域驱动设计方法的理论及实践经验。

基于 4A 一体化服务化设计方法模型介绍如何通过业务能力化、能力场景化、场景活动化、活动对象化、对象服务化、服务系统化六大步骤，实现从业务到系统的一体化设计。前三步业务能力化、能力场景化和场景活动化是逐步将大颗粒的业务能力分解细化成小颗粒的业务活动，接下来的两步活动对象化和对象服务化实现业务活动向数据操作的转换，将线条型的业务流程与业务活动转为模块化的数据操作功能，最后一步服务系统化是将小颗粒的服务组装为应用系统模块。

4A 融合服务化设计 V 模型中包含主要的业务要素、应用要素和数据要素。下面对核心要素进行解读说明。

业务能力是服务化变革的入手点。企业级的变革项目一般是面向企业愿景，驱动业务变革，引导和落实业务模式、组织架构和运营模式的变革。这些变革点首先体现在业务能力的变化中，进而落实到人才、流程和技术工具的变更 。

业务场景是业务流程的分类。不同业务人员对业务能力进行分解的维度(也称为场景因子)可能不相同，但只要符合 MECE 分析法(Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”)，并根据关键场景因子覆盖了全部关键业务活动，对最终设计应用服务的影响不大。

业务组件/业务服务是将一组可重用的业务活动及串接逻辑封装起来，面向不同场景提供一个完整的业务功能。一个业务能力可以提供一个或多个业务组件。业务组件对外提供标准化接口，通过灵活编排，快速实现复杂多变的业务场景。业务组件内部的优化不影响对外的接口，有利于业务的敏捷和创新

工作流/业务活动及其下层的任务。业务活动是业务人员描述和设计业务的最小单元，包括业务角色、输入输出交付件和业务规则。业务活动的颗粒度非常重要，不同部门编制和发布的业务活动的颗粒度可能差别很大。

本方法论对业务活动的颗粒度进行了原则性约束。业务活动也是 IT 设计师分析与设计应用服务中承载业务规则和数据规格的最小单元，业务活动根据处理的业务对象可以跨业务场景地合并到应用服务中。业务流程中的业务活动一般只体现出正向活动/任务，应用服务中的活动/任务需要包括正向、逆向和查询三类，以便更全面地描述系统功能。正向活动表示对数据的创建，逆向活动表示对数据的修改和删除，查询类活动表示对数据的查询和搜索。

业务对象是可以独立存在的数据实体，可以分解为逻辑数据实体，进而再分解为属性字段。业务对象相当于“领域驱动设计”方法(DDD)中的聚合根(Aggregate Root)，是一个业务领域的数据实体代表。业务对象也是数据治理的最小单元。围绕着业务对象可以设置数据 责任人，制定数据治理流程和指标。

应用服务相当于“领域驱动设计”方法(DDD)中定义的一个有界上下文(Bounded Context)，业务对象相当于有界上下文中的聚合根，是应用服务的核心，也是将围绕业务对象的业务活动归拢到应用服务的依据。关于有界上下文(Bounded Context)及聚合根(AggregateRoot)的概念及介绍看参考业界“领域驱动设计”的专业书籍。

应用服务既是业务要素，又是应用要素，封装了业务对象和围绕业务对象的业务活动，并以 API 的方式暴露系统功能。应用服务是业务、信息和功能的聚合，实现业务、数据与系统功能的拉通。如果对应用服务独立部署，则应用服务是业务架构、信息架构、应用架构和技术架构的结合体。应用服务不应由业务人员或 IT 人员单独设计，应组织业务代表、系统分析师 BA、信息架构师 IA 和系统架构师 SE 等角色共同设计。

应用系统模块是产品部署的物理单元。一个或几个关联紧密的应用服务组合为一个应用系统模块。应用系统模块的颗粒度不宜过小，否则可能出现应用服务间过于频繁的信息交互，导致服务运营困难。

将 4A 一体化服务化设计方法 Y 模型的核心元素根据业务、数据、应用分析与设计步骤逐次展开，形成服务化设计方法元模型 。本文将介绍设计流程中的前 10 步，从业务能力到应用系统模块的整体性设计。后面步骤属于一个应用服务内部的详细设计，不在本文范围内 。

01 业务能力化

所谓能力是为实现某一特定目标的一组人力、流程和技术的集合。

能力管理指组织基于价值贡献，结合公司客户价值主张，来定义能力绩效目标，以剔除低效能力并聚焦能带来财务收入的高效能力。业务能力设计一般是面向整个企业层面，根据企业的业务模型与治理模型，首先框定出企业的业务领域和业务子领域，然后在业务子领域内设计核心类和使能类业务能力。比如数字化可视、数字分析、智能辅助决策等数字化能力属于使能类业务能力。

业务能力定义的是干什么，而非怎么做。 能力(根据业务的复杂程度可能还会有更多层级)，每下一层，能力会更加细化。

一个企业的业务能力地图展示了一个企业或一个业务领域的业务行为。一个行业的业务能力地图基本是相似的。

02 能力场景化

业务能力可能会因为地理区域、业务或运作模式等的不同而有差异，因此能力需要支撑多场景。举例来说，不同的订单类型可能会来自于不同的商业模式，这就需要在“订单接收”和“订单处理”能力下建立多重场景。

业务场景是业务流程的分类。可以通过 5W1H 分析辨识场景因子，比如组织形态、业务对象、业务模式、地区、时间周期等要素。例如，交付内容和履约方式是 OM 的场景识别要素，交付内容分为设备、软件和服务;履约方式分为：PO 履约和项目履约。

对场景因子根据重要性确定主次顺序，然后分层次设计 To Be 业务流程。不同业务人员识别的场景因子和优先级顺序可能是不同的，没有绝对的对错，核心是基于场景因子设计的业务流程将业务活动包含完整。

用工作流来描述 HOW“怎么做”，从而实现该能力。

在工作流中，有逻辑关系的一系列业务活动支撑能力如何实现

“谁”应该作为“角色”被呈现。

“什么时候”表述执行时间点。

“为什么”作为 KPI，用以度量客户价值如何被影响。

03 场景活动化

基于业务场景因子对业务能力的分解，形成由业务活动组成的业务工作流。业务活动是表达业务的最小单位，通过得到完整的业务活动列表，可以形成完整业务的最小颗粒度视图。

解读工作流

定义

工作流是可以被重复执行，逻辑上相互关联的一组业务活动序列，将明确的输入转换成明确的输出，从而实现向客户交付价值(产品和服务)的业务目的。工作流分不同的级别，从描述企业增值的端到端工作流到描述一个角色具体活动的工作流。

六大要素

客户：是流程服务的对象，对外来讲是单位服务的个人或组织，对内来讲是流程的下一个环节。

价值：是流程运作为客户带来的好处，很多情况下不是用货币来衡量的，可以表现为提高了效率、降低了成本、减少了人员等。

活动：是流程运作的环节。

关联：是环节之间的关系，把流程从头到尾串联起来。

输入：是运作流程所必须的资源，不仅包括传统的人、财、物，而且包括信息、关系、计划等。

输出：流程运作的结果，它应该承载流程的价值。

编写要求

• 工作流图采用泳道图的编制标准，需要有清晰的角色定义和各角色对应的业务活动

• 业务活动的命名采用业务语言，明确表达业务行为

• 如存在重要外部依赖或输入，应标明在工作流图中

• 描述工作流图中的核心变革点与设计点，包括流程活动与业务规则

• 描述工作流中流程流转的判定条件，业务活动的业务逻辑、输入、输出以及异常情况

解读业务活动

定义

业务活动是流程的基本单元，是一组相互联系的、有明确成果和输出的任务或行动。业务活动一般以动宾结构来命名(动词+名词)，从而角色与业务活动组成完整的主谓宾逻辑关系。如：确认客户资信度、评审方案。

编制要求

• 每个活动由一个角色来负责，某些活动可以有协同参与的角色共同完成活动，但如果某项活动存在多个责任角色，需要拆分成不同活动，以便各负其责。

• 每个活动都有明确的输入、输出，如果存在多个活动，其责任角色相同，输入、输出相同，则建议对这些活动进行合并。

• 一般来说，流程活动描述要能直接指导业务操作，但对于较复杂的活动，可以下挂操作指导书做进一步的细化说明。

• 流程活动的颗粒度没有严格的衡量标准，对于业务成熟度高(作业相对标准化、自动化率较高、员工技能娴熟等)的流程活动描述可以概括、简练，反之则要细化和详细一些;流程活动的颗粒度还与 IT 相关，如果业务操作的 IT 化率较高，则流程活动描述相对概括、简单，反之亦然。

• 描述活动的输入信息，包括信息内容(What)和来源(From)。输入内容指本活动的开展所需要的前置依赖信息或依据，输入信息载体一般是业务对象、逻辑实体或者属性。输入的来源可能是前序活动的输出、外部系统、线下表单等。

• 描述活动的输出信息，包括信息的内容(What)和可能的使用者(TO)。输出信息载体一般是业务对象。

业务活动的颗粒度原则

业务活动在服务化方法 V 模型中位置非常重要，是识别业务对象的基础。如果业务活动的颗粒度太大，则不具备业务对象的辨识要求，颗粒度太小，则影响后续的抽象与合并，为了保证业务活动的颗粒度合适，在设计业务活动时，需遵循如下 10 个原则。

明确的业务目的：一个活动需要有明确的业务目的。如果一个活动与相邻的活动的业务目的相同，则考虑是否可以合并。

特定的业务价值：一个活动应该有特定的价值。如果两个活动的业务价值完全相同，则可以考虑合并。

单一的责任角色：一个活动可以有多个配合角色，但责任角色应该单一。如果责任角色不单一，建议对活动细化拆分。

稳定明确的输入：如果活动的输入项的结构不稳定且不明确，建议细化拆分。一个活动在不同的场景下，可以有不同的输入项，但输入项的结构应该是稳定且明确的。

稳定明确的输出：如果活动的输出信息结构不稳定且不明确，建议细化拆分。

完整的业务规则：约束活动的执行过程。业务规则应该是完整和稳定的，保障稳定和明确的输出。

符合 SOD(Seperation of Duty)职责分离原则：不相容职责应相分离，实现合理的组织分工。例如一个公司的授权、签发、核准、执行、记录工作，不应该由一个人担任。一般来说，活动执行主体不应同时拥有执行权限和管理权限。

明确的执行方式：说明此活动是人工线下执行、人工线上交互执行还是系统自动执行。

不跨部门：如果一个活动跨部门，建议细化拆分。

不跨系统：如果一个活动跨系统，建议细化拆分

04 场景活动化

由业务活动组成的业务工作流是线条型的，而系统功能是模块型的，如何将线条型的业务流程转化为模块型的系统功能，一个很重要的步骤，是将业务活动进行对象化设计。

业务活动对象化设计是指将业务活动的输入、输出和处理逻辑抽象设计为数据对象和对数据对象的操作。这样一组变化频度相同且变化原因相同的数据对象中最有业务代表意义的数据对象，我们称为业务对象。业务对象可以视为这一组数据对象的聚合根，外部可以通过业务对象访问到这组数据对象。

业务对象是数据治理的基础单元，可以通过对业务对象设定数据责任人、数据标准权威数据源和数据治理流程，实现对数据的治理。

(一) 解读业务对象

概念定义

业务对象是业务领域中某种具有连续性和标识的人、事、物、地的对象，用来统一业务领域的重要业务概念，是业务人员之间以及业务人员与系统人员之间沟通的桥梁，是识别变革项目涉及的信息范围和关键信息的依据，明确信息定义和关联关系的基础。业务对象对应数据概念模型中的概念实体。

设计原则

业务对象应很容易被业务人员理解，在业务领域范围内独立、唯一、相对稳定，不应区分场景，不应区分状态，不应区分载体。

设计方法

1. 基于业务能力和业务场景设计业务领域 To Be 的业务工作流(含业务活动)。

2. 识别业务工作流中每个业务活动的输入、输出等 BI(Business Item)。

3. 根据业务对象的特征对活动的 BI 进行判断，形成业务领域内的业务对象列表。

4. 根据一个业务对象归属一个业务领域的原则，对跨领域的业务对象，定义唯一数据 责任人和领域。

解读业务对象特征

业务对象是业务领域级别的。有些业务对象跨多个业务领域，比如“产品”，在不同业务领域中，会生成属于本业务领域的属于“产品”的逻辑实体和属性。这种情况，“产品”可以视为本业务领域的业务对象，负责维护本业务领域内的逻辑实体和属性。

业务对象可以独立存在。独立存在表示其对象实例不会没有自主权地随着其他业务对象实例的消亡而消亡。独立存在与业务的先后关系的概念不同，比如销售订单根据合同创建，但销售订单是独立存在的，有自己的生命周期和状态变化，并不随着合同实例的消亡而消亡。

业务对象有唯一性身份标识信息。可以通过唯一标识区分、准确检索和支持跨领域分布式共享引用业务对象的实例。

业务对象有生命周期，有状态变化。业务对象一般具有一定的生命周期，在其生命周期中有状态变化。状态的变化对应着业务操作和触发条件。

业务对象之间是关联关系。数据对象之间的依赖关系一般分为关联和归属两种。业务对象之间是关联关系，不是所属关系。只有关联关系，才能保证业务对象是独立的。与之对应的，逻辑实体与业务对象之间是归属关系，不是关联关系，逻辑实体是业务对象的一部分，随着业务对象的消亡而消亡。另外，是否需要明确的变更流程，也可以用来辨别两个业务对象是不是归属关系。比如 PO 变更会引起了 CO 变更，需要走明确的变更流程，可以说明 PO 和 CO 是关联关系，如果是从属关系，不需要额外变更流程。

业务对象是业务领域的核心。对于业务对象，通常会建立组织、流程和 IT 系统进行管理。当前是否已经有组织、流程和 IT 系统对业务对象进行管理，不作为业务对象的判断依据。

(三) 设计业务对象

业务对象是通过分析业务活动的输入和输出 BI(Business Item)，尤其是输出，而设计形成的。在传统的业务流程中，输入输出一般会对应业务活动要处理的“表证单书”。

第一步：识别业务对象

对业务领域中的所有业务活动的 BI 进行逐个分析，确定每个 BI 所属的业务对象。

如果一个 BI 符合业务对象的特征，则此 BI 是一个业务对象。

如果一个 BI 不符合业务对象的特征，则此 BI 应该不能独立存在，继续确定此 BI 归属的业务对象。因为只有业务对象是独立存在的，如果一个 BI 不能独立存在，则一定会属于一个业务对象。比如，如果一个 BI 是一个属性，则确认此属性所属的逻辑数据实体，然后再确认此逻辑数据实体归属的业务对象。一个 BI 一定可以找到所属于的业务对象。当将所有业务活动的输入输出都分析完毕，则应找到了理论上存在的本业务领域涉及到的所有的业务对象。

第二步：合并业务对象

两个业务对象是否可能进一步抽象合并为一个业务对象，可以参照如下五个原则。同时满足这五个原则的业务对象，可以考虑抽象合并为同一个业务对象。

实现类似的业务目的

承载类似的业务行为

包含类似的逻辑数据结构和属性

类似的生命周期和状态变化

类似的与其他业务对象的关联关系

第三步：验证业务对象和数据模型

领域间验证

将分析设计形成的业务对象与其他业务领域的业务对象进行比对，如果发现名字相同或相近的业务对象，需要考虑是否为同一个业务对象。如果确实不是同一个业务对象，则需要在名称上进行区分，以免造成混淆。

逻辑数据实体验证

一个业务对象可以分解和覆盖不同的逻辑数据实体，不同业务对象分解和覆盖的逻辑数据实体一般不相同;反之，一个逻辑数据实体不可以归属于不同的业务对象。

软件包验证

产品化的软件包出于业务普适性的需要，其数据对象的设计一般是很稳定的。我们可以参照行业领先软件包的业务对象和逻辑数据实体，优化和修正我们自己的业务对象和逻辑数据实体。

(四) 概念数据模型建模

审视业务对象与 BI 之间的关系。业务活动的 BI 是否都可以对应到业务对象、逻辑数据实体和属性字段三层。如果存在没有业务对象覆盖的 BI，则需要重新梳理本业务领域的业务对象。

审视业务对象之间的关系。业务对象之间的关系表达了业务对象的可视范围。两个业务对象直接关联，表示一个业务对象可以调用另一个业务对象。所以，业务对象之间的关联关系是设计应用服务最重要的输入。

应当尽量简化业务对象之间的关系。首先，去掉可有可无的、环状多路径的关系;其次，将双向的关系尽量简化为单向关系。

如果业务对象之间的关系很紧密，则适合归属到同一应用服务。比如两个业务对象之间的信息交互是双向的，则最好归属到同一个应用服务中。

如果两个关联的业务对象分属于两个应用服务，则这两个应用服务之间应该存在信息集成交互接口。

简化业务对象之间的关系。尽量简化业务对象之间的关系，可以通过将双向关系简化为单向关系来约束业务对象的访问方向，用单向箭头表示单向访问。

包含主要的逻辑数据实体。概念数据模型中属于业务对象的逻辑实体可以是初始化设计，在逻辑数据模型中会进行详细设计。

(五) 业务对象的属性识别原则

分析业务对象包含的属性，一般基于业务功能性需求，不需要考虑数据存储方式、呈现方式和非功能性需求。其原则包括：

– 必须通过本业务对象实例获取逻辑对象和属性值。

– 必须通过本业务对象进行创建和修改。如果信息源头的属性发生变更，需要正式通知本业务对象变更相应属性，则该属性属于本业务对象;如果信息源头的属性发生变更，不需要通知本业务对象变更相应属性，则改属性不属于本业务对象。

– 随业务对象的消亡而消亡。

– 已经归档的交易数据不能修改。

– 两个业务对象之间的关系，一般是关联关系，不是归属关系，关联关系需要识别并保存。

为保证服务的独立和完整性，容忍跨服务的数据适当冗余，通过技术手段保证最终一致性。以数据的冗余来拆解服务间的强耦合。冗余的数据一般包括为：

– 作为单独数据表冗余。比如通过事件消息保持数据最终一致性的消息日志。

– 作为属性冗余。比如其他业务对象的名称。

反模式—不作为属性归属业务对象的依据

– 前台界面展示的需要。前台应用与中台服务层需要解耦，前台聚集的信息可以来自多个中台应用服务。

– 下游活动的需要。下游活动应从数据源获取数据，而不能依靠非数据源的上游活动进行数据透传。

– 系统集成的需要。不能为了减少系统集成点，而违背数据源头获取数据的原则。

05 对象服务化

象封装的一组数据对象以及对数据对象的操作，可以暂且视为一组最小的系统功能单元。通过审视业务对象之间的耦合性，即变化原因和调用关系，分析是否需要将紧密关联的业务对象归属到一个系统功能单元中。紧密关联关系指两个业务对象的变化原因相同或存在联动的、双向的调用关系。这里说的变化，主要是说数据结构和数据操作的变化，变化原因就是导致数据结构和数据操作变化的原因。在分层设计原则中，还有一个变化，是数据展示的变化。

不同业务对象的数据结构、数据操作和数据展示的变化原因和变化频度，也是高内聚低耦合原则的判断依据。

这样一个最小的功能单元可以设计为一个应用服务。

1、服务定义

服务是指为他人做事，并使他人从中受益的一种有偿或无偿的活动。不以实物形式而以提供劳动的形式满足他人某种特殊需要。

业务服务是组织通过提供明确的服务接口实现某一特定能力的对外服务。(TOGAF Ver.9.1 , P23， The Open Group)

应用服务是指具备明确的业务特征，独立完整、由一个或多个关联紧密的功能组成的逻辑集合， 通过可重用的 API 对外提供能力。(摘自华为对应用服务的定义)

Web 服务(Web Service)是一个平台独立的、低耦合的、自包含的、基于可编程的 Web 的应用程序，可使用开放的 XML(标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。

2、服务的通用特征

公开可访问。对于应用服务来说，应该是以标准化的接口对外发布，外部应用可以通过网络调用的。可以通过权限进行访问者和访问范围控制。没有对外发布，纯粹内部使用的方法，不能称之为服务。

服务目录。就像饭馆的菜单一样，服务应有清晰明确的目录，通过服务的说明和样例，消费者可以对服务进行测试和调用。

业务完整。一个服务应该可以完成一个相对完整且独立的业务，而不能是片段式的。

功能稳定。服务接口相当于提供者和消费者之间的使用契约，其功能应相对稳定且保持版本向下兼容。

使用可定价、绩效可度量。服务应可以签订 SLA(服务等级协议)，根据承诺的服务等级，以调用次数的方式进行定价与计费。

3、应用服务的特征

1)业务特征

明确业务含义。每个应用服务应该提供具体业务功能，有明确的业务含义。不能指望一个应用服务实现全功能，包打天下。

围绕业务实体操作。应用服务一般围绕业务对象操作，对外暴露的 API 接口的颗粒度不宜过小，比如针对一个属性的 API 接口可能不合适。

业务职责完整单一。一个应用服务实现的功能应该是单一、确定且完整，既不能片段化也不能过于泛化。

业务功能稳定。应用服务不应随服务调用者改变而不得不变化。随着服务版本升级，业务功能应向下兼容。

颗粒度不宜太小。服务调用是有成本的，应尽可能减少各种跨服务调用的消耗。

2)技术特征

高内聚。应用服务应该有明确的边界，封装业务功能和业务数据，不暴露内部实现细节。聚合因同一理由变化的功能与数据，分离因不同理由而变化的功能与数据。

低耦合。应用服务之间应该横向解耦，一个服务的改变不应导致其他服务必须改变。应用服务内部应该纵向解耦，每层内部的变化不应导致其他层必须改变。服务调用者与服务提供者解耦，不能因为一方变动，另一方必须改变。

为分布式而生。应用服务更多是为提供外部进程调用服务，调用者不应关心服务在远程还是本地。调用者通过网页服务请求或者远程调用通信的方式进行通信。

接口标准化。一类应用服务的接口应该对应一组报文。一组报文内通常包含服务申请报文、服务结果返还报文等。

接口稳定。服务接口调用者不应随着应用服务内部实现逻辑的变化而变化，应用服务的接口应具有一定的扩展性，保证其稳定性。

与开发语言无关。调用者应不必也无需关心应用服务采用的技术栈和具体实现逻辑。

与数据存储方式无关。调用者应不必也无需关心应用服务采用的数据存储方式和具体实现细节。

3)运营特性

可注册。应用服务的 Public API 需要注册到 API 管理平台，形成服务目录，供服务消费者订阅调用。

可监控。可以监控应用服务的运行状态，可以启停应用服务。

可度量。应用服务的绩效可以度量，包括订阅数量、调用次数、响应时间等绩效指标。

可定价。根据服务调用次数或者数据流量进行定价核算。

有价值。超过 3 个月没有调用记录的应用服务，应该考虑是否需要下架，以保证应用服务都是有价值的。

4、应用服务的设计原则

应用服务设计是对处理一个或一组紧密关联的业务对象的业务活动的集合。应用服务的功能独立且完整，包含一个或者一组紧密关联的业务对象，以及一组围绕这些业务对象的业务操作。应用服务基于变化原因将业务对象与业务规则高内聚在一起，可访问、可衡量、可测试。

应用服务设计把能力服务化，实现能力的共享和自我进化;解耦单体大系统为适中规模的应用系。模块，快速响应业务需求。

产品团队要能基于应用服务的详细设计及项目路标主动规划产品及版本。

5、应用服务的数据类型分类

根据应用服务操作的业务对象的类型不同，可以分为交易类、主数据管理类和分析展示类应用服务。

交易类应用服务，包含一个或者一组紧密关联的交易数据类型的业务对象。此应用服务是业务对象的责任人 ，其 API 围绕业务对象进行操作，一般包括单个业务对象的 CRUD 增删改查操作、触发业务对象状态变化的操作以及管理业务对象关联关系的操作。

主数据管理类应用服务，围绕主数据构建的应用服务，包括主数据的 CRUD 增删改查等操作。

分析展示类应用服务，不是业务对象的责任人，一般基于 OLAP 分析型系统提供报告数据，或者位于交易类应用服务上层，通过调用交易类应用服务的 API 来聚集和组合交易数据，一般只提供获取类操作，不提供更改类操作。

审视业务活动与应用服务之间的关系

审视业务活动与应用服务之间的关系是否合理

– 一般地，一个业务活动由一个应用服务承载，一个应用服务承载一个或几个业务活动。

– 如果一个业务活动不对应任何一个应用服务。需要分析该业务活动是否为完全线下操作。如果该业务活动需要应用系统支撑，则应该对应一个应用服务。

– 如果一个业务活动对应多个应用服务。需要分析业务活动是否符合业务活动颗粒度原则，如果活动的颗粒度太大，需要进一步拆分。

– 如果一个应用服务承载了很多业务活动。需要分析应用服务中作为宿主的业务对象包含的逻辑数据实体是否过多或者关联的业务对象是否过多。可以考虑对大颗粒度的业务对象根据逻辑实体或属性分组进行拆分。

接下来需要重新审视业务活动与应用服务之间的关系，调整业务活动和应用服务的合理性。

说明：本示例是某项目中的真实案例，典型说明了审视业务活动与应用服务之间关系的重要性。通过此环节可以重新审视业务活动与业务对象设计的合理性，体现了业务活动(BA 核心内容)、业务对象(IA 核心内容)和应用服务(AA 核心内容)之间的融合设计。

在此示例中，25 个业务活动表示了订单管理域内所有的业务行为，7 个事物类的服务表示订单管理域的 7 个应用功能单元。

条件和检查发货单的背发货条件的业务规则有较大差异。“检查备发货条件”这个活动应归属于各自业务对象管理服务，不合适作为单独的应用服务;

对象，建议进行活动的拆分;

4 个规则类主数据管理服务：作为应用服务调用的公共数据服务，重点是讲清楚规则计算逻辑。

“发货批次”：如果没有“发货批次”业务对象，则不应该存在”发货批次管理服务”，则与此相关的活动需要由“销售订单管理服务”来承载。这样会造成销售订单管理服务非常庞大，建议将“发货 批次”作为单独的业务对象，并设计“发货批次管理”服务。

“销售订单管理服务”承载了非常多的业务活动，需要进一步分析销售订单的属性是否可以分组，根据职责单一原则，拆分为独立的应用服务。

最后再次审视应用服务之间的关系，以进一步确认其合理性。主要从业务、数据、运营三个视角和分层原则进行审视

业务角度

– 审视应用服务是否能够支撑所有业务场景和业务流程。

数据角度

– 审视应用服务是否包含了所有的业务对象?

– 审视应用服务之间的协同关系覆盖了业务对象之间的关联关系?

– 审视应用服务是否包含了所有负责业务对象的状态变化的 API?

– 审视应用服务是否包含了负责维护业务对象之间的关联关系的 API?

– 审视应用服务发布的 API 是否是业务对象级别的操作?因为业务对象是业务领域中的聚合根，应避免提供围绕逻辑数据实体和属性的更改类 API

技术角度

– 审视应用服务之间是否存在循环调用?服务之间不能存在循环调用!

– 审视应用服务是否存在跨层调用?一般不建议跨层调用!

– 如果一个服务应用只被另外一个应用服务调用，则可以考虑合并为一个应用服务。

06 服务系统化

每个应用服务原则上具备了可以独立部署的能力，但为了部署发布和运维的考虑，我们可以将几个应用服务在物理上合并在一起部署发布，形成一个应用系统模块。下面介绍服务化应用架构的主要元素和原则。

解读服务化应用架构

前台 UI 与中台服务分离，可以作为 App 单独部署;

前台 UI 根据显示设备的不同，可以分别开发和部署;

服务有层级，不能循环调用，根据变化的频度进行分层，包含的业务对象决定了层级;

服务根据变化的原因和频度解耦;

每个服务应保持独立性，功能完整且单一;

服务之间通过 Rest API 或者消息进行通信;

API Gateway 对 API 调用进行路由、安全和组装管理;

不同的服务对基础设施的需求可能不同;

不同的服务相应上层的调用频度可能不同;

不同的服务根据硬件资源(CPU、内存、网络等)占用特点可以有单独的部署策略，比如乘客服务和司机服务因为访问量不同，其部署策略应该也不相同。

对于分层设计的应用服务，其 API 调用关系需要遵从：上层服务的 API 可以调用下层服务的 API，不允许循环调用。

应用服务的分层原则

根据服务内容变化的频率，将应用服务进行分层。上层的应用服务，更靠近用户，变化频率更快，下层的应用服务，相对更稳定。

一个应用服务位于一层中，不跨层。

业务对象决定应用服务所处的层次。

交易和数据总是沿着层次从上向下流动的。

上层的应用服务可以调用下层的应用服务(通过 IP 地址、URL、API 或者消息队列)。

下层的应用服务并不知晓上层应用的存在，可以通过暴露 API 供上层调用，但不知道具体的调用者。

下层应用服务可以发布只读的数据供上次应用服务使用。

应用系统模块的设计考虑因素

一个或者一组应用服务可以物理组合为一个应用系统模块，应用系统模块的划分可以考虑业务、技术、运维三方面因素。

(1)业务因素

– 高内聚低耦合原则。保持应用系统模块内部高内聚，应用系统模块之间的依赖最小化;

考虑业务变更原因。将业务变更原因相同的数据和功能聚合在一起，将变更原因不同的数据和功能相分离。

考虑业务变更频率。将变化频度高与变化频度低的应用服务分组在不同的应用系统模块中。

– 单一职责。保持应用系统模块功能完整性且职责单一，避免设计功能大而全的应用系统模块。

(2)技术因素

– 在将服务划分到不同的应用系统模块时，减少分布式数据库事务;

– 根据服务对数据一致性的要求，如实时一致性还是最终一致性，划分应用系统模块;

– 根据技术栈划分应用系统模块，一个应用系统模块中避免使用两种或以上技术栈类型的服务;

– 划分应用系统模块时，避免服务间出现循环依赖、双向依赖的问题， 永远只有不同层级的单向依赖，高层服务可以依赖低层服务，同层服务间不互相依赖;

(3)运维因素

– 考虑应用服务的资源占用情况。根据 CPU 与内存的占用类别与占用大小，将应用服务进行分组在不同的应用系统模块中，以便将来可以对资源占用率高的应用服务动态横向扩展;

– 应用系统模块的划分应与 DevOps 团队规模与交付频率相匹配;

– 迭代演进，非一蹴而就。

最后设计应用系统模块的应用集成架构，重新审视应用服务之间的调用关系。

应用集成架构需要包括的元素：

应用子域系统架构视图

与本系统有直接信息交互的系统

标明信息交互的方向

标明实现信息交互的集成技术

基于集成架构需要审视

集成架构与 API 的关系。审视已经设计的 API 是否支撑了服务间的集成关系。

集成架构与技术实现的关系。审视使用的集成技术是否符合华为及项目的要求。

集成架构是否支撑了工作流程。审视服务集成关系是否支撑完整的工作流程。

每个六边形表示一个应用(同服务化 V 模型中的应用服务)。其中，乘客前台(PASSENGERWEB UI)、司机前台应用(DRIVER WEB UI)可以视为前台应用;乘客管理(PASSENGERMANAGEMENT)、司机管理(DRIVER MANAGEMENT)和旅程管理(TRIP MANAGEMENT)可以视为中台应用;开票管理(BILLING)、支付管理(

PAYMENT)可以视 为后台应用。消息服务(NOTIFICATION)可以视为基础平台技术服务;

不同类型的显示终端，可以有不同的前台应用来支撑;手机端应用一般会使用服务网关对下层的服务 API 调用进行合并与封装;

应用之间通过 RESTFUL API 或者消息进行通信;

每个应用是独立和自治的。每个应用对自己领域内的数据负责。每个应用可以根据需要选择最适合的技术栈，包括开发语言、开发框架和数据存储方式等;

应用是分层的，上层可以调用下层提供的服务，而下层不可以调用上层的服务;

根据访问量和对资源要求的不同，应用可以有不同的部署策略。比如乘客管理的访问量与司机管理的访问量不是一个数量级，可以有针对性地部署相应的服务数量;

每个应用的责任团队应该是自治的。与服务化架构相匹配，每个应用的团队应该是自治的，负责应用的全生命周期，包括构建和运营。

服务化体系架构的价值

通过构建服务化体系架构，可以支持不同层次/类型的 DIY“编排”，敏捷支撑一线项目作战场景。

小应用，快速灵活响应业务变化。基于服务设计实现的轻应用，松耦合，独立交付影响面小，交付效率提升，快速响应业务变化。

快速扩展，成效好。横向扩展便利，只需要扩展所需部分，扩展性更强、成本更低。

快速开发、高频部署。各个服务独立开发、独立部署、独立运营，提高开发效率和部署频率，降低测试时间和部署风险。

复用服务，灵活插拔，可柔性编排。通过对服务的复用和编排快速实现新的业务场景。通过对服务的优化和调整来快速实现业务活动的操作变化。