企业官网建设流程全解析

1. 架构这个词被用滥了：四类架构到底在回答谁的什么问题

做了这么多年架构设计和评审，我有个特别直观的感受：开会的时候，只要有人说出"架构"两个字，接下来大概率要进入鸡同鸭讲环节。产品经理嘴里的架构、数据组理解的架构、研发负责人脑中的架构，往往不是一个东西。有人说的是业务怎么流转，有人说的是数据库怎么分表，还有人说的是服务怎么拆。大家都很认真地讨论，但最后发现彼此根本不在一个维度上。

这个问题的根源，就是我们常说的"业务架构、数据架构、应用架构和技术架构"这四层没有在讨论前先对齐。它们不是同一个东西的四个叫法，而是四个不同的问题、四套不同的模型、四种不同的关注尺度。把这个问题想清楚，比学会任何一款建模工具都重要。这篇文章我就想从实际项目视角把这四层彻底掰开揉碎，讲讲每层到底管什么、怎么产出、彼此怎么配合，也会把我在实际评审中踩过的坑一并写出来。

好，先从一个最常见的场景说起。

1.1 一次评审会上的鸡同鸭讲

我参加过很多次新项目立项评审。有一次印象特别深，是一个零售企业的订单中台项目。业务总监上来第一页PPT写的是"提升订单履约效率，优化售后体验"，这是典型的业务视角。接着数据负责人开口说，我们要先做数据架构，把订单、库存、会员的核心数据模型定清楚，否则后面全是空中楼阁。技术负责人马上接话：数据模型晚点再说，先把应用架构定下来，确定要拆哪几个微服务、接口怎么定。最后运维的老同事幽幽补了一句：你们定了这么多服务，容器平台和监控体系得跟上，这是技术架构的活。

四十分钟过去了，四个人都在讲"架构"，但谁也没回答谁的问题。业务说目标，数据说模型，应用说服务，技术说基建。你说他们错了吗？每个人在自己的维度上都没错，但合在一起，项目照样没法开工。因为缺少一个把四种架构串起来的整体框架，每个人都在凭经验认定"应该先干我的活"。

这件事之后我养成了一个习惯：任何涉及多方协作的架构讨论，第一件事不是画图，而是先定义这个项目里"架构"这个词指的到底是哪个维度，每个维度要回答什么问题，产出什么交付物。把规则定清楚，再开始聊具体内容。

1.2 四类架构的"业主"与"提问维度"

我对四类架构的理解，可以用四个问题来概括：

• 业务架构回答：企业到底要做什么事，怎么创造价值？
• 数据架构回答：支撑这些业务，需要哪些数据，数据之间什么关系，怎么流转和治理？
• 应用架构回答：用哪些软件系统或服务来实现业务能力，它们之间怎么协作？
• 技术架构回答：这些系统跑在什么基础设施上，用什么技术组件来保障运行？

这四层之间有清晰的依赖顺序，业务架构定义需求，数据架构围绕业务定义数据的组织方式，应用架构把业务能力变成软件能力，技术架构给这些软件能力提供运行环境。

为了在项目里能直接使用，我做了一张简单对照表，挂在评审会议室的墙上，非常管用。这里也分享给你：

这张表最大的价值，是让每个参会者在开口说"架构"之前，先自动补一句"我说的是哪层架构，回答的是哪个问题"。就这一个动作，评审会的效率至少翻一倍。

2. 业务架构：价值链与业务能力的显式建模

业务架构在很多人眼里是最虚的一层。做技术的觉得它是流程梳理，做业务的觉得它是PPT，最后大家都不做。但我负责任地说，跳过业务架构是大部分项目后期返工的根源。业务架构的核心不是画流程图，而是把企业"会做什么"这件事显式地建模出来。

2.1 业务架构的核心元素：业务能力、价值流与组织边界

业务架构有三大核心元素：业务能力、价值流、组织职责。先说业务能力。业务能力指的是企业"具备的做某件事的本事"，它不依赖具体流程和系统。举个例子，零售企业有"订单管理能力""库存管理能力""售后服务能力"，这些能力不会因为你上了套新系统就消失，它是业务自身长期积累的结果。

价值流则描述"为了给客户创造价值，一系列能力是如何被串起来的"。从客户下单到收到货，这条价值流串联了订单管理、支付结算、库存分配、物流调度、售后管理等能力。价值流是动态的、面向结果的，业务能力是静态的、面向组织积累的。两者配合起来，业务架构才是完整的。

组织职责则是第三个必须回答的问题：每项能力由哪个部门、哪个团队负责。这个在架构上叫RACI（责任分配矩阵）的业务版。没有组织边界，业务架构就是一张好看但管不住的网。

2.2 把业务架构落到纸面的实操步骤

我梳理业务架构的方法比较简单，不一定用多重的工具，几张A3纸就能启动：

1. 先定边界，明确这个业务架构覆盖的范围是集团、事业部还是单条产品线。边界不清，后面的能力地图就是无底洞。
2. 找能力清单，从价值流反推。把"从获客到回款""从下单到履约"这类主干价值流画出来，每一步背后一定对应至少一项业务能力，全部列出来。
3. 给能力分层分级。顶级能力下再拆子能力，一般拆到三级就够用。例如"库存管理"之下可以有"库存查询""库存预留""库存调拨"。
4. 做能力与组织职责的映射。每项能力必须指明唯一的责任部门，可以共享执行，但责任归属一定要明确。
5. 验证价值流是否跑得通。把主干价值流和子价值流按照"能力—流程—系统"的链路走一遍，看哪些环节有断裂。

这里我想强调一个经验：业务架构不要贪大求全。第一次做，能梳理出一条主线价值流和十项左右的核心能力就可以了。很多团队一上来就铺全公司几十个部门，业务能力画了上百个，最后根本维护不下去。业务架构是一个持续活化的资产，而不是一次性交付的文档。

2.3 业务架构为什么常被跳过，以及跳过后的代价

业务架构被跳过，原因倒也好理解：它不直接产出代码，也不是运维能监控的指标，老板看不到直接的进度条。项目中一旦时间紧、资源少，第一个被砍掉的就是业务架构。

但代价会在后续埋得很深。我见过一个供应链项目，跳过业务架构直接做数据和应用设计。研发团队按自己的理解设计了库存模型和应用模块，上线后才发现业务上存在多种库存形态：可售库存、在途库存、锁定库存、残次库存。每种库存的扣减规则完全不同，但由于没先做业务能力梳理，应用层为适配业务补丁打了无数个，数据的混乱更是到了不可收拾的地步。最终只能回炉重做，工期翻倍。

业务架构不是可有可无的，它是其他三层架构的输入源头。尤其是当领域里出现了新形态，比如物联网场景下的三层架构讨论，很多团队的误区就是直接奔着"感知层、网络层、应用层"去做技术设计，却忽略了业务架构首先要定义"通过设备采集数据要支撑什么业务能力、产生什么价值"。我建议在物联网这类新技术驱动的新业务中，反而应该先把业务架构补扎实，再谈后面的数据、应用和技术架构。

3. 数据架构：从数据模型到数据资产的落地逻辑

如果说业务架构回答"做什么"，数据架构回答的就是"靠什么数据支撑来做"。企业级数据架构的复杂程度，往往超乎技术团队的想象，因为数据不像代码，它在很多部门之间流转，天然带有政治属性。

3.1 数据架构的四个层次：模型、存储、流转、治理

在日常评审中，我需要把数据架构拆成四个层次来讲：数据模型、数据存储、数据流转、数据治理。

数据模型是数据架构的地基，包括概念模型、逻辑模型、物理模型。概念模型定义核心业务概念和关系，比如客户、订单、产品之间的关系。逻辑模型在概念模型基础上补全属性、主键、外键以及业务规则。物理模型则落到具体的数据库表结构、分区策略、索引设计。

数据存储解决"数据放在哪里"。常见的有关系型数据库、数据仓库、数据湖、NoSQL、缓存等。选择存储方式要结合数据特性，而不是一味追新。大数据架构里说的"四个层次"，通常指采集、存储、计算、应用服务，这本质上也是数据存储和流转的分层思路，只不过把范围从单一系统拉到了整个大数据平台。

数据流转描述数据从产生、加工、集成、消费的完整路径。这里最容易出问题的是链路混沌，一份数据被多个系统重复加工、口径不一，最后不同报表同一个指标数字对不上。每次看到"以哪份数据为准"的争论，源头多半是数据流转没有设计清楚。

数据治理在整个体系里容易被忽略，但它是确保数据可信的保障。数据标准、数据质量规则、数据安全分级、元数据管理、数据生命周期管理，都属于治理范畴。我见过不少团队，模型设计非常漂亮，一上线就发现了脏数据没人处理、虚假数据无人负责，就是因为治理没跟上。数据治理不用一开始就铺得很大，但至少要把"数据责任人和数据质量标准"这两件事定下来。

3.2 数据架构与业务架构的映射关系

数据架构不能脱离业务架构凭空设计。我常用的方法是做"业务能力—数据实体"的映射矩阵。每一项业务能力，列出它必须依赖的数据实体，然后检查这些数据实体的归属关系。

举个例子，"库存管理能力"必然依赖"库存余额""库存变动记录""补货单"等数据实体。"订单管理能力"依赖"订单头""订单行""订单状态变更历史"等。把这些映射列出来，就能发现两类问题：一是有些能力依赖的数据实体完全没人负责，也就是数据生产方缺失；二是有些数据实体被多个能力共用，但没有明确唯一的数据主源，这就是数据不一致的隐患。

在实际项目中，我会在数据架构设计阶段要求团队先把"每个核心数据实体，谁生产、谁消费、谁负责质量"这张表填完。填完这张表，再去建库建表，方向会清晰很多。

3.3 主数据、数据中台与领域数据模型的边界

数据架构里有很多名词容易混淆，主数据、数据中台、领域数据模型，听起来都和数据有关，但作用域完全不同。

主数据是跨业务共享的基础数据，比如客户、产品、供应商、组织架构。它的特点是相对稳定，变化频率低，一旦错误会波及所有下游系统。主数据管理要做的事，是保证这套基础数据在各系统间同源、同步、同标准。 在零售、制造、金融行业，主数据做不好，后续应用架构无论怎么设计都会在数据一致性上栽跟头。

领域数据模型则是某个业务域内部的业务对象模型，比如订单域里的订单、支付域里的支付记录。领域数据模型是应用架构中微服务划分的重要依据之一。很多团队做微服务的时候不喜欢先看数据模型，直接按组织架构拆，拆完才发现服务之间数据纠缠不清。

数据中台则是这几年被过度神话的名词。我一直持有保守观点，数据中台本质上是把企业数据资产通过采集、加工、服务化的方式，向前台业务提供统一数据能力，定位是"数据的加工厂和服务台"。但如果企业连主数据和核心领域数据模型都没理清，盲目建中台只会把数据问题变得更加复杂。我自己经手的项目里，好几家建了中台却没用起来，原因是中台输出的数据口径与应用系统对不上，各系统依然各算各的。

所以我的建议是：先理清主数据和核心领域模型，再决定要不要建中台。这个顺序不能反。

4. 应用架构：系统边界、服务划分与集成方式

应用架构是很多研发团队最熟悉的层面，但熟悉不等于理解到位。应用架构不是画几个方框连线就算完成，它必须回答"系统怎么划分、职责怎么界定、系统之间用什么方式协作"这三个具体问题。

4.1 应用架构到底画的是什么样的图

很多人会把应用架构图和技术架构图混为一谈。我告诉你一个简单的判断方法：应用架构图里出现的每一个模块，都必须能用一句话说清"这个模块支撑了哪个业务能力"；技术架构图里出现的每一个组件，必须能用一句话说清"这个组件保障了什么运行能力"。

比如，一个"订单服务"出现在应用架构里，它的职责应该是"提供订单的创建、查询、状态流转能力"，它对应业务架构里的"订单管理能力"。但如果你在应用架构图里画的是"Nginx"或"Redis集群"，那说明你画歪了，那是技术架构层面的东西。

应用架构常见的图上元素包括：应用系统或服务、应用功能、应用接口、应用之间的依赖关系和数据流。在设计时，我习惯先画一张系统上下文图，把目标系统放在中间，把所有上下游系统标出来，再细化内部的应用组件。这样做的好处是先明确边界，避免系统本身和外部依赖纠缠不清。

4.2 从业务能力到应用模块的推导规则

应用架构不是拍脑袋定的，它应该从业务架构推导。我常用的推导规则有三个：

第一，一个业务能力对应至少一个应用模块。能力是业务层的原子单元，应用模块是能力的软件载体。例如"库存预留能力"，在应用层往往对应"库存服务"里的一个预留接口。

第二，按数据归属划分服务边界。两个应用模块如果频繁读写同一份核心数据表，基本可以判断它们应该合并，或者需要通过明确的接口解耦。数据归属是应用边界最硬的一条线。

第三，按团队与部署边界确定服务粒度。服务不是拆得越细越好，而是要看有没有独立团队负责、能不能独立发布。一个服务如果改一行代码需要同时跟其他服务一起发布，那它其实不是一个独立服务。

在建模工具方面，我个人比较推荐ArchiMate这类标准建模语言。它把应用层内部元素之间的依赖关系画得非常清楚，比如"应用功能"可以"实现"为"应用服务"，应用服务又会被"业务服务"调用；应用组件内部可以有"应用功能"，组件之间通过"应用接口"交互。这里有一个关键点需要留意：ArchiMate中应用层和技术层的关系是"部署"和"实现"，应用组件被部署在技术节点上，应用接口可以被技术服务实现。画图时别把应用层元素和技术层元素放在同一层混着连线，否则看的人会产生严重的误解。

4.3 单体、SOA、微服务：应用架构演进中的取舍

应用架构不是只有微服务一种形态。很多团队一说要做中台、要数字化转型，上来就拆微服务，这是个大的误区。

单体架构在业务复杂度和团队规模不高时，反而是性价比最高的选择。它的优势是开发部署简单、调试方便、事务一致性强。缺点是"随着业务的增长"（原谅我用了这句常见套话，这里是实情）模块间耦合会变得让人头疼，团队协作成本升高，但这并不意味着每个系统都必须走向微服务。

SOA的核心思路是服务化加企业服务总线，它更适合跨系统、跨部门的集成场景，它的价值在于服务的复用和治理，但总线本身也会成为性能瓶颈。微服务则是把SOA的思路进一步细化，把服务粒度缩小到业务能力级别，并强调去中心化治理和按团队独立交付。

我给出的选型建议有三条：

1. 先考虑团队规模和交付节奏。少于三个研发团队，不要贸然拆微服务。
2. 先考虑数据一致性要求。强事务场景优先考虑单体或粗粒度服务，不要把一个事务拆到多个服务再用分布式事务硬扛。
3. 先考虑集成复杂度。外部系统多、接口多的场景，要先定义好服务契约和集成规范，再决定服务化深度。

应用架构的演进途径，应该是"单体起步—模块化拆分—必要时服务化"，而不是一步到位。

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 架构评审时必备的追问清单

我在评审架构方案时，有一个固定的追问流程，简单但极其有效：

1. 这个架构调整，支撑的是哪项业务能力？如果答不上来，说明脱离业务架构。
2. 核心数据的唯一源在哪里？如果多个系统都有权改动同一数据，数据架构一定有问题。
3. 这个服务的边界和团队边界一致吗？如果不一致，组织协同成本会直接拖垮交付。
4. 技术选型对应的是当前业务阶段还是想象中的未来？如果是为了想象中的未来过度设计，说明技术架构脱离现实。
5. 链路中最薄弱的一个环节在哪？所有技术架构都必须回答最坏情况下的表现。

这些问题看起来简单，但真能逼着团队把架构讲清楚。卡壳的地方，就是需要重新设计的地方。

7.2 最常踩到的几个大坑

第一个坑是"业务架构当流程图画"。很多团队把业务流程图画一遍，就声称完成了业务架构。业务流程只是价值流的一部分，业务架构还包含能力地图、组织职责、非功能性约束等。只画流程图，后面做应用架构时一定会发现职责不清、边界模糊。

第二个坑是"数据架构被应用架构绑架"。有些团队把每个数据库表的设计直接当作数据架构的全部，完全忽略了数据在生产、消费、治理层面的复杂性。等系统上线后，跨系统的数据一致性问题会让你焦头烂额。

第三个坑是"应用架构跟着组织结构走"。最常见的微服务划分是按照公司部门来拆的，财务一个服务，人力一个服务，订单一个服务。这种做法短期内方便，长期看服务和业务能力是错位的，接口会越写越绕。我建议用业务能力加数据归属来划服务，而不是拿部门墙当边界。

第四个坑是"技术架构跟业务目标脱节"。团队为了自嗨引入高复杂度组件，却说不清这些组件保障了哪项非功能需求。技术架构的每一个组件，都应该能回答"它到底保护了什么、支撑了什么"。

7.3 我的实践原则：让四层架构以最小约束的方式持续对齐

最后说说我如今推进架构的方式。我不会再追求一次性把四层全部做到完美，而是采用"由痛点驱动、分层对齐"的策略。项目中遇到什么问题，就针对这个问题的层面做架构设计和评审，同时只关注相邻层的对齐。

比如这次优化订单核心链路，那就从业务能力层看订单履约这条价值链，再落到订单和库存的数据模型，再看应用层服务划分，最后看技术层容量和可用性。其他与这条链路关系不大的部分，一律不做大改动。这样既避免了架构重构的阵痛，又确保了关键链路的架构一致性。

四层架构从来不是一套静态的文档，它是一套思考问题的方式。业务架构告诉你为什么而做，数据架构告诉你依赖什么资产，应用架构告诉你用软件怎么实现，技术架构告诉你用什么承载。每层的建设节奏和详略可以根据企业实际情况调整，但层与层之间的逻辑链一定要贯通。

我特别想强调的一点是，业务架构是整个体系的起点。如果业务架构失真，后面三层再精细也是建在沙地上。现实中很多架构师不擅长业务分析和价值流梳理，但恰恰是这项能力决定了技术方案能否真正解决业务问题。

真正好的架构，是在持续的交付过程中不断演化的。别怕一开始不完美，但一定要保证每一轮迭代后，四层架构的逻辑链都是完整可追溯的。这比一张完美但没人看懂的架构图有价值得多。