1. 架构这个词被用滥了四类架构到底在回答谁的什么问题做了这么多年架构设计和评审我有个特别直观的感受开会的时候只要有人说出架构两个字接下来大概率要进入鸡同鸭讲环节。产品经理嘴里的架构、数据组理解的架构、研发负责人脑中的架构往往不是一个东西。有人说的是业务怎么流转有人说的是数据库怎么分表还有人说的是服务怎么拆。大家都很认真地讨论但最后发现彼此根本不在一个维度上。这个问题的根源就是我们常说的业务架构、数据架构、应用架构和技术架构这四层没有在讨论前先对齐。它们不是同一个东西的四个叫法而是四个不同的问题、四套不同的模型、四种不同的关注尺度。把这个问题想清楚比学会任何一款建模工具都重要。这篇文章我就想从实际项目视角把这四层彻底掰开揉碎讲讲每层到底管什么、怎么产出、彼此怎么配合也会把我在实际评审中踩过的坑一并写出来。好先从一个最常见的场景说起。1.1 一次评审会上的鸡同鸭讲我参加过很多次新项目立项评审。有一次印象特别深是一个零售企业的订单中台项目。业务总监上来第一页PPT写的是提升订单履约效率优化售后体验这是典型的业务视角。接着数据负责人开口说我们要先做数据架构把订单、库存、会员的核心数据模型定清楚否则后面全是空中楼阁。技术负责人马上接话数据模型晚点再说先把应用架构定下来确定要拆哪几个微服务、接口怎么定。最后运维的老同事幽幽补了一句你们定了这么多服务容器平台和监控体系得跟上这是技术架构的活。四十分钟过去了四个人都在讲架构但谁也没回答谁的问题。业务说目标数据说模型应用说服务技术说基建。你说他们错了吗每个人在自己的维度上都没错但合在一起项目照样没法开工。因为缺少一个把四种架构串起来的整体框架每个人都在凭经验认定应该先干我的活。这件事之后我养成了一个习惯任何涉及多方协作的架构讨论第一件事不是画图而是先定义这个项目里架构这个词指的到底是哪个维度每个维度要回答什么问题产出什么交付物。把规则定清楚再开始聊具体内容。1.2 四类架构的业主与提问维度我对四类架构的理解可以用四个问题来概括业务架构回答企业到底要做什么事怎么创造价值数据架构回答支撑这些业务需要哪些数据数据之间什么关系怎么流转和治理应用架构回答用哪些软件系统或服务来实现业务能力它们之间怎么协作技术架构回答这些系统跑在什么基础设施上用什么技术组件来保障运行这四层之间有清晰的依赖顺序业务架构定义需求数据架构围绕业务定义数据的组织方式应用架构把业务能力变成软件能力技术架构给这些软件能力提供运行环境。为了在项目里能直接使用我做了一张简单对照表挂在评审会议室的墙上非常管用。这里也分享给你架构维度回答的核心问题主要产出物最难面对的提问业务架构做什么生意靠什么能力赚钱关键流程如何流转业务能力地图、价值流、组织职责矩阵这个能力到底归谁管数据架构哪些数据是核心资产数据模型长什么样谁生产谁消费概念模型、逻辑模型、数据分布矩阵、治理规范这个数据的唯一来源在哪应用架构系统边界在哪服务怎么划分系统间怎么集成系统上下文图、应用组件清单、接口契约、集成方案这个服务为什么归这个团队技术架构基础设施、中间件、框架如何选型与部署部署拓扑、技术选型说明、容量规划、运维规范这套方案的可用性和成本是多少这张表最大的价值是让每个参会者在开口说架构之前先自动补一句我说的是哪层架构回答的是哪个问题。就这一个动作评审会的效率至少翻一倍。2. 业务架构价值链与业务能力的显式建模业务架构在很多人眼里是最虚的一层。做技术的觉得它是流程梳理做业务的觉得它是PPT最后大家都不做。但我负责任地说跳过业务架构是大部分项目后期返工的根源。业务架构的核心不是画流程图而是把企业会做什么这件事显式地建模出来。2.1 业务架构的核心元素业务能力、价值流与组织边界业务架构有三大核心元素业务能力、价值流、组织职责。先说业务能力。业务能力指的是企业具备的做某件事的本事它不依赖具体流程和系统。举个例子零售企业有订单管理能力库存管理能力售后服务能力这些能力不会因为你上了套新系统就消失它是业务自身长期积累的结果。价值流则描述为了给客户创造价值一系列能力是如何被串起来的。从客户下单到收到货这条价值流串联了订单管理、支付结算、库存分配、物流调度、售后管理等能力。价值流是动态的、面向结果的业务能力是静态的、面向组织积累的。两者配合起来业务架构才是完整的。组织职责则是第三个必须回答的问题每项能力由哪个部门、哪个团队负责。这个在架构上叫RACI责任分配矩阵的业务版。没有组织边界业务架构就是一张好看但管不住的网。2.2 把业务架构落到纸面的实操步骤我梳理业务架构的方法比较简单不一定用多重的工具几张A3纸就能启动先定边界明确这个业务架构覆盖的范围是集团、事业部还是单条产品线。边界不清后面的能力地图就是无底洞。找能力清单从价值流反推。把从获客到回款从下单到履约这类主干价值流画出来每一步背后一定对应至少一项业务能力全部列出来。给能力分层分级。顶级能力下再拆子能力一般拆到三级就够用。例如库存管理之下可以有库存查询库存预留库存调拨。做能力与组织职责的映射。每项能力必须指明唯一的责任部门可以共享执行但责任归属一定要明确。验证价值流是否跑得通。把主干价值流和子价值流按照能力—流程—系统的链路走一遍看哪些环节有断裂。这里我想强调一个经验业务架构不要贪大求全。第一次做能梳理出一条主线价值流和十项左右的核心能力就可以了。很多团队一上来就铺全公司几十个部门业务能力画了上百个最后根本维护不下去。业务架构是一个持续活化的资产而不是一次性交付的文档。2.3 业务架构为什么常被跳过以及跳过后的代价业务架构被跳过原因倒也好理解它不直接产出代码也不是运维能监控的指标老板看不到直接的进度条。项目中一旦时间紧、资源少第一个被砍掉的就是业务架构。但代价会在后续埋得很深。我见过一个供应链项目跳过业务架构直接做数据和应用设计。研发团队按自己的理解设计了库存模型和应用模块上线后才发现业务上存在多种库存形态可售库存、在途库存、锁定库存、残次库存。每种库存的扣减规则完全不同但由于没先做业务能力梳理应用层为适配业务补丁打了无数个数据的混乱更是到了不可收拾的地步。最终只能回炉重做工期翻倍。业务架构不是可有可无的它是其他三层架构的输入源头。尤其是当领域里出现了新形态比如物联网场景下的三层架构讨论很多团队的误区就是直接奔着感知层、网络层、应用层去做技术设计却忽略了业务架构首先要定义通过设备采集数据要支撑什么业务能力、产生什么价值。我建议在物联网这类新技术驱动的新业务中反而应该先把业务架构补扎实再谈后面的数据、应用和技术架构。3. 数据架构从数据模型到数据资产的落地逻辑如果说业务架构回答做什么数据架构回答的就是靠什么数据支撑来做。企业级数据架构的复杂程度往往超乎技术团队的想象因为数据不像代码它在很多部门之间流转天然带有政治属性。3.1 数据架构的四个层次模型、存储、流转、治理在日常评审中我需要把数据架构拆成四个层次来讲数据模型、数据存储、数据流转、数据治理。数据模型是数据架构的地基包括概念模型、逻辑模型、物理模型。概念模型定义核心业务概念和关系比如客户、订单、产品之间的关系。逻辑模型在概念模型基础上补全属性、主键、外键以及业务规则。物理模型则落到具体的数据库表结构、分区策略、索引设计。数据存储解决数据放在哪里。常见的有关系型数据库、数据仓库、数据湖、NoSQL、缓存等。选择存储方式要结合数据特性而不是一味追新。大数据架构里说的四个层次通常指采集、存储、计算、应用服务这本质上也是数据存储和流转的分层思路只不过把范围从单一系统拉到了整个大数据平台。数据流转描述数据从产生、加工、集成、消费的完整路径。这里最容易出问题的是链路混沌一份数据被多个系统重复加工、口径不一最后不同报表同一个指标数字对不上。每次看到以哪份数据为准的争论源头多半是数据流转没有设计清楚。数据治理在整个体系里容易被忽略但它是确保数据可信的保障。数据标准、数据质量规则、数据安全分级、元数据管理、数据生命周期管理都属于治理范畴。我见过不少团队模型设计非常漂亮一上线就发现了脏数据没人处理、虚假数据无人负责就是因为治理没跟上。数据治理不用一开始就铺得很大但至少要把数据责任人和数据质量标准这两件事定下来。3.2 数据架构与业务架构的映射关系数据架构不能脱离业务架构凭空设计。我常用的方法是做业务能力—数据实体的映射矩阵。每一项业务能力列出它必须依赖的数据实体然后检查这些数据实体的归属关系。举个例子库存管理能力必然依赖库存余额库存变动记录补货单等数据实体。订单管理能力依赖订单头订单行订单状态变更历史等。把这些映射列出来就能发现两类问题一是有些能力依赖的数据实体完全没人负责也就是数据生产方缺失二是有些数据实体被多个能力共用但没有明确唯一的数据主源这就是数据不一致的隐患。在实际项目中我会在数据架构设计阶段要求团队先把每个核心数据实体谁生产、谁消费、谁负责质量这张表填完。填完这张表再去建库建表方向会清晰很多。3.3 主数据、数据中台与领域数据模型的边界数据架构里有很多名词容易混淆主数据、数据中台、领域数据模型听起来都和数据有关但作用域完全不同。主数据是跨业务共享的基础数据比如客户、产品、供应商、组织架构。它的特点是相对稳定变化频率低一旦错误会波及所有下游系统。主数据管理要做的事是保证这套基础数据在各系统间同源、同步、同标准。 在零售、制造、金融行业主数据做不好后续应用架构无论怎么设计都会在数据一致性上栽跟头。领域数据模型则是某个业务域内部的业务对象模型比如订单域里的订单、支付域里的支付记录。领域数据模型是应用架构中微服务划分的重要依据之一。很多团队做微服务的时候不喜欢先看数据模型直接按组织架构拆拆完才发现服务之间数据纠缠不清。数据中台则是这几年被过度神话的名词。我一直持有保守观点数据中台本质上是把企业数据资产通过采集、加工、服务化的方式向前台业务提供统一数据能力定位是数据的加工厂和服务台。但如果企业连主数据和核心领域数据模型都没理清盲目建中台只会把数据问题变得更加复杂。我自己经手的项目里好几家建了中台却没用起来原因是中台输出的数据口径与应用系统对不上各系统依然各算各的。所以我的建议是先理清主数据和核心领域模型再决定要不要建中台。这个顺序不能反。4. 应用架构系统边界、服务划分与集成方式应用架构是很多研发团队最熟悉的层面但熟悉不等于理解到位。应用架构不是画几个方框连线就算完成它必须回答系统怎么划分、职责怎么界定、系统之间用什么方式协作这三个具体问题。4.1 应用架构到底画的是什么样的图很多人会把应用架构图和技术架构图混为一谈。我告诉你一个简单的判断方法应用架构图里出现的每一个模块都必须能用一句话说清这个模块支撑了哪个业务能力技术架构图里出现的每一个组件必须能用一句话说清这个组件保障了什么运行能力。比如一个订单服务出现在应用架构里它的职责应该是提供订单的创建、查询、状态流转能力它对应业务架构里的订单管理能力。但如果你在应用架构图里画的是Nginx或Redis集群那说明你画歪了那是技术架构层面的东西。应用架构常见的图上元素包括应用系统或服务、应用功能、应用接口、应用之间的依赖关系和数据流。在设计时我习惯先画一张系统上下文图把目标系统放在中间把所有上下游系统标出来再细化内部的应用组件。这样做的好处是先明确边界避免系统本身和外部依赖纠缠不清。4.2 从业务能力到应用模块的推导规则应用架构不是拍脑袋定的它应该从业务架构推导。我常用的推导规则有三个第一一个业务能力对应至少一个应用模块。能力是业务层的原子单元应用模块是能力的软件载体。例如库存预留能力在应用层往往对应库存服务里的一个预留接口。第二按数据归属划分服务边界。两个应用模块如果频繁读写同一份核心数据表基本可以判断它们应该合并或者需要通过明确的接口解耦。数据归属是应用边界最硬的一条线。第三按团队与部署边界确定服务粒度。服务不是拆得越细越好而是要看有没有独立团队负责、能不能独立发布。一个服务如果改一行代码需要同时跟其他服务一起发布那它其实不是一个独立服务。在建模工具方面我个人比较推荐ArchiMate这类标准建模语言。它把应用层内部元素之间的依赖关系画得非常清楚比如应用功能可以实现为应用服务应用服务又会被业务服务调用应用组件内部可以有应用功能组件之间通过应用接口交互。这里有一个关键点需要留意ArchiMate中应用层和技术层的关系是部署和实现应用组件被部署在技术节点上应用接口可以被技术服务实现。画图时别把应用层元素和技术层元素放在同一层混着连线否则看的人会产生严重的误解。4.3 单体、SOA、微服务应用架构演进中的取舍应用架构不是只有微服务一种形态。很多团队一说要做中台、要数字化转型上来就拆微服务这是个大的误区。单体架构在业务复杂度和团队规模不高时反而是性价比最高的选择。它的优势是开发部署简单、调试方便、事务一致性强。缺点是随着业务的增长原谅我用了这句常见套话这里是实情模块间耦合会变得让人头疼团队协作成本升高但这并不意味着每个系统都必须走向微服务。SOA的核心思路是服务化加企业服务总线它更适合跨系统、跨部门的集成场景它的价值在于服务的复用和治理但总线本身也会成为性能瓶颈。微服务则是把SOA的思路进一步细化把服务粒度缩小到业务能力级别并强调去中心化治理和按团队独立交付。我给出的选型建议有三条先考虑团队规模和交付节奏。少于三个研发团队不要贸然拆微服务。先考虑数据一致性要求。强事务场景优先考虑单体或粗粒度服务不要把一个事务拆到多个服务再用分布式事务硬扛。先考虑集成复杂度。外部系统多、接口多的场景要先定义好服务契约和集成规范再决定服务化深度。应用架构的演进途径应该是单体起步—模块化拆分—必要时服务化而不是一步到位。5. 技术架构基础设施、平台与质量约束技术架构是最容易被看见的一层也是容易被讨论成纯技术选型的一层。但真正合格的技术架构不只是选几个开源框架那么简单它要站在业务架构和应用架构的约束下设计一整套能长期稳定运行的支撑体系。5.1 技术架构的关注点与常见分层技术架构关注的内容可以分成六个维度计算资源、网络资源、存储资源、中间件、可观测性、安全合规。再具体一点落到技术栈上就是服务器与容器平台、网络与负载均衡、数据库与缓存、消息队列、日志与监控、权限与安全策略。我习惯把技术架构设计分为基础层、平台层、应用支撑层三个层次来看。基础层是机房或云上的IaaS资源比如虚拟机、Kubernetes集群、物理网络平台层是中间件和基础服务比如数据库、消息队列、对象存储、统一认证应用支撑层则是面向应用开发提供的通用能力比如API网关、配置中心、消息中心、分布式锁。分层的好处是每一层的变更可以独立评估不会牵一发而动全身。5.2 技术选型不是用最新而是匹配当前阶段技术架构里容易被情绪带偏的就是技术选型。团队里总有人推荐最新的框架、最新的中间件理由是社区活跃、生态好。这些理由没错但技术选型最重要的原则是匹配团队能力、匹配业务阶段、匹配运维条件。我常用一个简单的评估矩阵来帮团队做选型决策学习成本、社区成熟度、团队现有经验、业务规模预期、运维复杂度、长期授权成本。每项打1到5分最后加权排序。这个矩阵不能保证选到最完美的方案但能避免被最新技术忽悠。举个例子一个日活只有几万的管理系统引入一套完整的微服务全家桶再上Kubernetes和Service Mesh从成本和维护角度来说是灾难。业务复杂度还没有到那个程度过度设计的架构只会在故障排查时让团队崩溃。在技术架构设计里还要把非功能性需求当成一等公民。可用性、性能、容量、灾备、安全合规这些不是上线前再补的而是在技术架构设计阶段就要给出量化指标。比如可用性目标如果是99.95%那对应的负载均衡、数据库高可用、多可用区部署方案必须在架构图里反映出来。5.3 ArchiMate 技术架构内部元素关系举例有些朋友会问到ArchiMate我补充一个技术架构内部元素关系的例子。ArchiMate中技术层包含节点、基础设施功能、技术服务、技术接口和工件。核心关系有这么几类组合一个节点可以组合多个基础设施功能。典型例子是一台服务器节点上组合了计算功能、存储功能和网络功能。实现技术服务可以实现应用层的应用服务比如消息队列服务这个技术服务实现了应用层面的异步通知服务。关联基础设施元素之间的关系比如网络节点与存储节点之间的物理连接。部署工件被部署在节点上构件和艺术品的概念很多人容易混淆但记一个核心即可应用层组件部署到什么节点用的是部署关系。在实际画图时我更关注的是这些关系是否能在架构评审中讲清楚依赖链。比如一个核心交易链路从业务服务到应用组件再到技术服务最后到基础设施能否逐层追诉依赖关系。如果能说明这条链路的架构是通的如果中间断了那意味着存在未被显式设计的隐性依赖。很多线上故障正是源于隐性依赖在关键时刻突然失效。6. 四层架构如何像齿轮一样咬合一个订单履约系统的推演实例理论说多了容易飘我用一个订单履约系统来完整推演一遍四层架构的配合过程。这个案例相对常见大家能够结合自身经验去验证。6.1 先从业务架构出发价值流与能力拆解假设这是一家电商企业核心价值流是客户下单到完成履约。我们把价值流拆成几个关键阶段提交订单、支付校验、库存匹配、仓库出库、物流配送、确认收货、售后处理。每个阶段都能向后推导出对应的业务能力订单管理能力、支付结算能力、库存分配能力、仓储作业能力、物流调度能力、客户服务能力。到这一步业务架构的输入就清楚了。再往下每一项能力都要落到组织职责。库存分配能力归供应链部门订单管理能力归电商运营部门物流调度能力归物流部门。这些归属会影响后面应用架构的服务边界划分。6.2 再定义数据架构核心数据实体与数据流转业务架构出来后数据架构就有了明确的建模依据。围绕订单管理能力核心数据实体是订单头、订单行、订单事件记录。围绕库存分配能力核心数据实体是库存余额、库存预留记录、库存变动流水。围绕支付结算能力核心数据实体是支付单、退款单、账务流水。其间要明确几件关键的数据规则订单在数据库中的唯一标识是订单号支付单与订单是多对一的关系库存余额的扣减必须先预留后确认。数据生产的唯一源头也必须定清楚订单数据只能由订单服务创建任何系统都不能跨过订单服务直接写订单表。在数据流转上订单创建成功后会产生一个订单已创建事件这个事件被库存服务、支付服务监听用来触发后续动作。这里的数据流转设计直接决定了后面应用集成的方式。6.3 接着推应用架构模块划分与接口契约业务能力和数据实体都清晰后应用架构的划分就比较顺了。订单服务对应订单管理能力负责创建订单、查询订单、修改订单状态支付服务对应支付结算能力负责支付和退款库存服务对应库存分配能力负责库存查询、预留、扣减物流服务对应物流调度能力负责发运、轨迹同步。服务之间的集成方式在应用架构里必须明确。订单与支付之间用同步API交互因为支付结果是订单确认的必要条件订单与库存之间则通过事件驱动解耦订单创建后发布事件库存服务异步响应这样的好处是库存系统的瞬时峰值不会拖垮下单主链路。接口契约要在这时定清楚。比如库存预留接口的入参包含商品SKU、数量、订单号出参包含预留单号、是否充足、预计可发时间。契约定了技术架构才有明确的容量估算依据。6.4 最后落到技术架构栈与部署策略基于前面的应用架构技术架构就顺理成章了。场景是互联网零售需要支撑促销峰值因此选型可以偏云原生Kubernetes做容器编排PostgreSQL存核心交易数据Redis做热点缓存Kafka做事件消息ELK做日志检索Prometheus加Grafana做指标监控。数据库高可用采用主从复制跨可用区部署。消息队列做多分区支持库存预留事件的并发消费。API网关统一接入外部渠道的订单请求限流和鉴权在网关层完成。这一层架构的语言和前文提到的ArchiMate建模能够一一对应订单服务部署在Kubernetes节点支付服务通过技术服务调用数据库节点事件通过消息队列技术服务在服务之间传递。四层架构在这个案例里是逐层推导、环环相扣的。业务架构定义了需要什么能力数据架构定义了支撑能力需要的数据及数据规则应用架构把能力变成服务并定义好协作方式技术架构给这一切运行提供了底座。任何一层变了其他层都要跟着评估影响面这就是架构对齐的意义。7. 我在实际项目中的经验教训如何避免四层脱节推演很理想现实很骨感。真实项目里四层架构脱节是常态。我在这里把踩过的坑和总结出的经验教训分享出来能帮一个是一个。7.1 架构评审时必备的追问清单我在评审架构方案时有一个固定的追问流程简单但极其有效这个架构调整支撑的是哪项业务能力如果答不上来说明脱离业务架构。核心数据的唯一源在哪里如果多个系统都有权改动同一数据数据架构一定有问题。这个服务的边界和团队边界一致吗如果不一致组织协同成本会直接拖垮交付。技术选型对应的是当前业务阶段还是想象中的未来如果是为了想象中的未来过度设计说明技术架构脱离现实。链路中最薄弱的一个环节在哪所有技术架构都必须回答最坏情况下的表现。这些问题看起来简单但真能逼着团队把架构讲清楚。卡壳的地方就是需要重新设计的地方。7.2 最常踩到的几个大坑第一个坑是业务架构当流程图画。很多团队把业务流程图画一遍就声称完成了业务架构。业务流程只是价值流的一部分业务架构还包含能力地图、组织职责、非功能性约束等。只画流程图后面做应用架构时一定会发现职责不清、边界模糊。第二个坑是数据架构被应用架构绑架。有些团队把每个数据库表的设计直接当作数据架构的全部完全忽略了数据在生产、消费、治理层面的复杂性。等系统上线后跨系统的数据一致性问题会让你焦头烂额。第三个坑是应用架构跟着组织结构走。最常见的微服务划分是按照公司部门来拆的财务一个服务人力一个服务订单一个服务。这种做法短期内方便长期看服务和业务能力是错位的接口会越写越绕。我建议用业务能力加数据归属来划服务而不是拿部门墙当边界。第四个坑是技术架构跟业务目标脱节。团队为了自嗨引入高复杂度组件却说不清这些组件保障了哪项非功能需求。技术架构的每一个组件都应该能回答它到底保护了什么、支撑了什么。7.3 我的实践原则让四层架构以最小约束的方式持续对齐最后说说我如今推进架构的方式。我不会再追求一次性把四层全部做到完美而是采用由痛点驱动、分层对齐的策略。项目中遇到什么问题就针对这个问题的层面做架构设计和评审同时只关注相邻层的对齐。比如这次优化订单核心链路那就从业务能力层看订单履约这条价值链再落到订单和库存的数据模型再看应用层服务划分最后看技术层容量和可用性。其他与这条链路关系不大的部分一律不做大改动。这样既避免了架构重构的阵痛又确保了关键链路的架构一致性。四层架构从来不是一套静态的文档它是一套思考问题的方式。业务架构告诉你为什么而做数据架构告诉你依赖什么资产应用架构告诉你用软件怎么实现技术架构告诉你用什么承载。每层的建设节奏和详略可以根据企业实际情况调整但层与层之间的逻辑链一定要贯通。我特别想强调的一点是业务架构是整个体系的起点。如果业务架构失真后面三层再精细也是建在沙地上。现实中很多架构师不擅长业务分析和价值流梳理但恰恰是这项能力决定了技术方案能否真正解决业务问题。真正好的架构是在持续的交付过程中不断演化的。别怕一开始不完美但一定要保证每一轮迭代后四层架构的逻辑链都是完整可追溯的。这比一张完美但没人看懂的架构图有价值得多。