Question

我们此前提出的架构意图：

一个以企业管理应用为目的、以业务功能为核心的三层架构。

真的具有平台特性吗？真的是以平台为方向的一种架构意图吗？

答案是：未必。因为我们此前通过“架构形成模型 M0”提出的这一意图，是基于 系统构成 的，而上一小节讨论的平台/框架则是面向 系统的方向 来讨论的。尽管两个讨论中都用“三层架构 12 ”为例子，但实质上是不同的。

决定“系统架构的架构意图”的另一关键因素是对客户战略的把握。仍以“办公系统”为例，这里将至少涉及两类客户 13 ，其一是系统的实际 用户方 ，如某个公司的某个职员；其二是以“办公系统”为可销售产品的、开发者所在的系统 开发方 。为了后续的讨论，我们简化地做出两点假设：其一，主要的影响来自于用户方与开发方的战略；其二，上述战略要求办公系统能够长期而持续地添加或变更需求。

在战略决策过程中，“目标系统拿来做什么？”会是一个关键问题。它讨论了开发以及持续开发的必要性，后者更是进一步地决定了“以系统（这一规模下的）方法来架构它”的必要性。图 19 所示（重复于图 24 中）的架构模型是对上述问题的一个不错的回应，它意味着这个系统是满足“（用户方）功能渐增”这一需求的。

图 24　一个概要的系统架构的模型

对于一个基于该模型构建的系统，当功能增加时，只要这些功能可以被抽象为服务并置于框架层中，那么它必然可以作为产品的一部分发布或投放。J2EE 这一企业应用的解决方案本身作为一个系统实现了框架层与服务层的统一，并且在框架层与服务层提供了系统分布的解决方案。这样就一举解决了三类需求：

• 用户方在功能渐增上的需求；
• 开发方在产品封装与发布上的需求；
• 系统在（通过分布与部署来解决的）规模性上的需求。

但是这三点表现出来的是“框架层+服务层”对系统 运行逻辑 的约束，而非对系统在 数据性质 上的规划。因此这一方案以及由此形成的具体应用解决都是“框架”这个方向下的。

那么“用户方、开发方与系统”对于平台的需求为何呢？

平台是用于整合资源的，这是由平台本身“面向数据”这一特性而决定的。如果用户方或开发方具有整合资源的需求，无论这一资源是上下游的供应链（行为、活动或运营模式等），或是系统供求关系中的依赖物资（用户、时间或实际生产资料等），又或者是在多种资源之间通过某种方式转化（授权、交易或数据挖掘等），那么它都需要一个平台来描述这一资源的核心生存周期，并基于这一核心生存周期中的一个或多个阶段来构划平台。

平台的核心在于支撑，这意味着平台（或平台中的层次）对数据的持有是独占的——在同一平台中对数据的理解是一致的。如果不具有这种特性，那么应当增加一层数据抽象，并在该层次上再构建新的平台。

仍以办公系统为例，从用户方来看，一种提出“平台需求”的理由是 14 ：办公过程中的审核行为可能会涉及对多种外部活动（如工作流中的环节）的确认。那么这种情况下，审核对象应该可以理解为跨子系统的统一资源，因此应当对审核对象的生存周期（产生于何子系统，在何子系统中使用等细节）进行规划，并提出“平台化审核”的需求。这样一来，办公系统的架构意图就倾向于平台方向了，我们可能看到在将来的实施中，在办公系统中去整合工作流系统或具体业务系统，也可以整合决策系统等。因为从这些系统的特点来看：它们基于管理层次，通过审核来完成行为注册、提交、授权与验证等功能。

从开发方来看，也可能存在提出“平台需求”的理由。例如，开发方试图将“为企业定制办公系统”过渡到“开发通用办公系统，并提供企业定制服务”。如果有了这种需求，那么办公系统本身将需要被平台化，以整合其上的资源——各个“办公模块（子系统）”。

J2EE 这样的架构模型并不能很好地应对平台需求，因为它在核心上只是将服务理解为资源，这是“计算机系统”的视角而非业务视角。但是反过来看，这也意味着这样的架构模型在技术实现方面是可以平台化的，只是架构师需要从业务视角上对平台进行架构意图的展现、明确与推动而已。

三层或更多层，并不是平台化。层次是平台化的一种表现方法，而非平台——作为架构意图的本身，也并不是平台在应对战略问题中的核心关注点。