应用架构设计方法：先定系统层级，再校正能力归属，附华为案例方法

附件为52页PPTX文件。

应用架构设计首先不是识别功能，也不是梳理现有系统，而是确定应用系统的层级结构。只有先把应用域、应用组、一级应用系统和系统内部构件这几个层次立起来，功能、数据、角色和现有系统之间的归属关系才有稳定基础。因而，应用架构设计的本质，不是简单罗列能力，也不是一次性画出系统边界，而是在先行建立系统层级之后，再通过下层能力、流程关系和构件归属的不断检验，对上层结构持续校正，最终形成稳定的应用结构。

一、应用架构的起点，不是功能清单，而是系统结构

很多应用架构之所以做到最后沦为“功能汇总表”或者“现状系统图”，根本原因并不在于分析不够细，而在于起点就错了。一开始就从功能出发，看起来容易推进，实际上会带来两个直接后果：一是功能不断增加，但不知道应当归属于哪个系统；二是系统边界始终模糊，最后只能出现多个系统共同承担同一类能力、同一类数据被多处维护的局面。功能可以被识别，但功能不能自己决定归属；真正决定归属的，只能是系统层级。

因此，应用架构设计的第一步，必须先回答一个结构性问题：企业应用世界究竟由哪些层级的应用元素构成。只有这个问题先被回答，后续所有功能、数据、角色和服务，才有可能被放入一个清晰、稳定的结构中。应用架构从来不是在“功能池”里分配任务，而是在既定的系统结构中确定职责。

二、AD、AG、APP，不是概念堆砌，而是系统层级的建立过程

应用架构之所以需要 AD、AG、APP，不是为了把系统讲复杂，而是为了建立一个有秩序的系统层级。AD 是 Application Domain，即应用域。它界定的是企业应用版图中的领域边界，回答的是“企业应用首先应当按哪些领域来组织”。AG 是 Application Group，即应用组。它不是简单的业务分类，而是领域内部的治理分组，用来组织一组强相关的一级应用系统。再往下是 APP。APP 虽然被称为一级应用系统模块，但在规划语义上，它已经可以视为一级应用系统单元，也就是一个能够独立承接一组紧密相关业务活动的系统对象。

这三层的意义，不在于层级本身，而在于它们共同完成了一件事：先把企业应用的主结构立起来。AD 解决领域边界，AG 解决分组治理，APP 解决一级系统归属。没有这三层，应用架构就会停留在业务讨论层；有了这三层，应用架构才真正进入系统组织层。换句话说，AD、AG、APP 不是给功能找帽子，而是给系统立骨架。

三、只有一级系统还不够，应用架构必须继续进入构件层

如果设计停留在 APP 层，应用架构虽然已经有了一级系统，但仍然偏粗。原因在于，一个一级应用系统内部往往同时包含多类业务对象、多段流程环节和多种职责差异。如果不继续向下分解，所谓一级系统很快就会膨胀为一个什么都想承接、什么都难以界定的能力容器。这样的系统在规划阶段看似完整，一进入建设阶段就会暴露出内部职责混乱、功能耦合严重、演进困难等问题。

这正是 ABB 存在的理由。ABB 可以明确为 Application Building Block，即应用构件。它不是普通功能分组，而是一级系统内部可建设、可组合、可治理的结构单元。一个 ABB 应当围绕特定业务需求组织，由一组紧耦合功能构成，并保持构件内高内聚、构件间低耦合。到了这一层，应用架构才真正从“系统划分”进入“构件设计”。APP 解决的是一级系统承接什么业务能力，ABB 解决的是一级系统内部由哪些构件来支撑这些能力。没有 ABB，一级系统只是规划对象；有了 ABB，一级系统才具备可建设性。

四、功能识别不是起点，而是系统和构件建立之后的能力展开

当 APP 和 ABB 的层级关系建立起来以后，应用架构才真正进入功能设计阶段。这一点很关键。因为功能并不是悬空存在的，功能必须属于某个构件，构件必须属于某个系统。也正因如此，功能设计不应被理解为“尽可能把需求列全”，而应被理解为“在既定系统—构件结构中，明确每个构件到底承担哪些能力”。

这意味着，功能项应当能够对应明确的业务对象和业务动作，而不能停留在抽象管理概念上；进一步细化到功能子项，也不是为了把系统无限拆碎，而是为了使构件能力足以支撑具体业务步骤。功能一旦脱离构件和系统单独识别，就会变成无主能力；功能只有进入归属链条，才会成为应用结构中的真实内容。功能设计的价值，不在于把事情说得更细，而在于把能力放回它应在的位置。

五、应用架构不是一次性定型的，而是在由下向上的校正中逐步稳定

应用架构设计最重要的方法论，不是自上而下分层，而是先立上层结构，再由下向上完成校正。上层的 AD、AG、APP、ABB，最初都只是结构假设；它们究竟是否成立，最终要靠下层能力、业务流程、逻辑实体和功能归属来检验。如果下层能力无法自然收敛到既定构件中，如果构件无法稳定归属于既定系统中，那么问题就不在功能，而在上层结构本身。

所以，应用架构的真实过程，不是“先把层级画对，再往里面填内容”，而是“先提出层级框架，再用下层事实不断检验”。先根据业务和领域关系建立 AD、AG、APP 的主结构，再在 APP 之下识别 ABB；随后结合业务对象、流程动作和功能归属，观察这些下层元素究竟自然汇聚到哪个 ABB、哪个 APP；如果归属关系与原先结构不一致，就必须回过头调整构件划分和系统边界。所谓反复矫正，本质上就是由下向上的定型过程。真正稳定的架构，不是一次画对的，而是被不断推实的。

六、系统结构成立之后，还要让职责、映射和协作三类关系闭合

一套应用架构是否成熟，最终不取决于画了多少层，而取决于关系是否闭合。首先要闭合的是职责关系。每个 APP 和 ABB 必须清楚承接什么业务能力、处理什么业务对象，职责既不能重叠，也不能悬空。其次要闭合的是映射关系。业务步骤、业务角色、数据对象和现有系统，都必须能够映射到相应的应用元素上，否则架构只能停留在抽象层。再次要闭合的是协作关系。系统与构件之间如何交互、如何复用、哪些能力应当沉淀为服务，也必须被明确设计出来。

这三类关系一旦建立起来，应用架构就不再只是一个层级命名体系，而会转化为真正可建设、可治理、可演进的系统结构。系统层级解决的是“有哪些元素”，功能归属解决的是“这些元素承载什么能力”，职责、映射与协作解决的是“这些元素如何在现实中运行起来”。只有这三层问题连成一体，应用架构才算真正成立。

七、应用架构设计的真正难点，不在分层，而在收稳结构

从表面看，应用架构设计似乎是在做层级划分；但更深一层看，它真正处理的其实是结构稳定性问题。先定系统层级，是为了建立结构假设；再校正能力归属，是为了检验这种结构假设能否成立。凡是下层能力无法稳定承接、上层边界无法经受检验的系统划分，都只能算暂时性的分组，不是真正的架构。

因此，应用架构设计的本质，可以概括为一句话：先根据业务和领域关系建立系统层级，再通过能力、流程、构件与系统之间的逐步归属，对上层结构持续校正，最终形成一套职责清楚、关系稳定、可以映射现实系统并能够支撑服务复用的应用结构。应用架构的难点，从来不在于列出多少功能，也不在于画出多少层级，而在于能否建立一个经得起下层能力检验的系统结构。真正成熟的应用架构，不是被画出来的，而是在不断校正中被收稳的。

八、华为应用架构设计方法