应用架构的三个理解误区

误区一是把应用架构用在单个应用内部——应用架构关注的从来不是一个应用本身，而是如何通过一个应用体系去实现[[高速公路”类比：企业战略与业务架构的关系|业务架构]]的目标；单个应用自己内部的架构应该叫”应用功能架构”（包含该应用各个功能模块），二者是不同层级的概念，应用架构图里的基本架构元素应该是”一个应用”，而不是某个应用内部的功能模块。误区二是忽视应用拆分的成本——拆分带来的成本至少有两方面：网络通信的时间成本、为实现通信容错性带来的项目预算和维护成本；更容易被低估的是拆分之后的整合成本，拆分本身容易，整合往往更具挑战性；现实中常见的问题是系统被零散拆分之后，整合阶段发现交互关系变成了复杂的网状结构，且随时间推移调整越来越困难——正因如此，[[应用拆分先看业务定位，整合看三个维度反向检验|拆分和整合]]必须在编排层面综合考虑，拆分是为了更好整合，整合也能反过来促成合理的拆分。误区三是忽略非功能性需求在应用架构设计中的重要性——应用架构风格主要由非功能性需求决定，而不应该只是简单沿用企业原有已经在用的某种架构风格；进行应用架构设计时必须充分考虑非功能性需求的影响和约束条件，而非默认延续过去的惯性选择。可迁移启发：审查一份应用架构设计，可以直接检验它有没有踩中这三个误区——架构图的基本元素是不是”应用”级别而非功能模块级别、有没有在文档里体现出对拆分/整合成本的权衡、架构风格的选择依据是不是写清楚了对应的非功能性需求，而不是一句”我们一直是这么做的”。