本文转载自 什么是技术架构、数据架构、业务架构、应用架构和代码架构？，在原文基础上有所增减。
很多团队讨论架构时容易把层次混在一起。一个明明属于业务边界的问题，被拿到代码层争论；一个明明属于数据治理的问题，被当成部署问题处理…本文把这些架构放进同一条分析链路里，重点回答三个问题：
- 每一层架构到底在解决什么问题
- 不同层次之间的边界应该怎么划
- 团队在设计系统时应该从哪一层开始思考
架构首先是一种控制复杂度的方式
架构不是画图本身，架构是对系统的抽象描述。系统规模一旦上来，模块会增多，依赖会扩散，角色会变复杂，变化频率也会提高。没有分层，团队看到的就只剩一团纠缠在一起的实现细节。
所以架构的首要作用，是把复杂系统拆成多个可理解、可演进、可协作的层次。拆分后的系统至少要满足几件事：
- 横向上可以并列观察不同模块
- 纵向上可以从高层目标逐步落到低层实现
- 整体上可以随着业务和技术演进而调整
如果把这件事讲得更直接一点，架构的价值在于帮团队识别问题属于哪一层，然后在正确的层次上做决策。
先用几种经典框架建立观察视角
在进入五类架构之前，先看几个常用框架。它们不直接替你做设计，但能帮你建立观察系统的坐标系。
4+1 视图：从不同角色看同一个系统
4+1 视图把系统拆成五个互补视角：逻辑视图、开发视图、过程视图、物理视图和场景视图。它的意义不在于规定团队必须画成同一种图，而在于提醒你，同一个系统会被不同角色以完全不同的方式理解。
- 逻辑视图：从功能组织角度描述系统由哪些能力组成
- 开发视图：从开发者角度描述代码包、模块、库和工程结构
- 过程视图：描述运行过程中的交互、时序和并发关系
- 物理视图：描述系统如何部署到机器、网络和基础设施上
- 场景视图：通过关键用例把前面几种视图串起来
它给团队的启发很简单：如果你只用一种图解释系统，通常只解释了系统的一部分。
C4 模型：从上下文一路下钻到代码
如果说 4+1 解决的是从哪些角度看系统，那么 C4 模型 解决的是从哪个抽象层级看系统。它把系统拆成四层：
- Context：系统和外部用户、外部系统之间的关系
- Containers：系统内部主要运行单元，例如服务、应用、技术组件
- Components：单个容器内部的主要模块
- Code：代码层的接口、类、对象和实现关系
C4 的价值在于，它强迫团队区分抽象层级。很多争论之所以无效，原因常常是双方站在不同层级说话。一个人在谈系统上下文，另一个人在谈某个模块类怎么拆，当然很难达成一致。
TOGAF：把企业级架构拆成四个稳定层
TOGAF 提供了另一种更接近企业治理的拆法：业务架构、应用架构、数据架构、技术架构。
- 业务架构：战略、组织、治理、业务能力和关键业务流程
- 应用架构：应用系统清单、职责边界、交互关系以及它们如何承接业务流程
- 数据架构：核心数据资产、数据模型、数据流转和数据管理方式
- 技术架构：支撑应用和数据运行的技术平台、基础设施、中间件、网络和标准
这套分类非常实用，因为它天然适合回答企业里最常见的几个问题：业务怎么拆、系统怎么承接、数据怎么治理、平台怎么支撑。
五类架构分别在回答什么问题
结合上面几个框架，可以把本文讨论的五类架构理解为一条从上到下的展开链路：
- 业务架构决定系统为什么存在，以及它提供哪些业务能力
- 应用架构决定这些能力由哪些应用承接，以及应用之间怎么协作
- 技术架构决定这些应用用什么技术形态运行，以及如何满足稳定性、性能和扩展性要求
- 数据架构决定核心数据如何建模、流转、隔离和治理
- 代码架构决定开发者如何在单个应用内部组织实现
它们并非彼此替代，关注点分属不同层次。
业务架构：定义价值、边界和主流程
业务架构最上层。它关心的是平台或产品在业务上到底承载什么能力，面对哪些角色，有哪些主流程，哪些环节属于核心，哪些环节属于辅助。
这一层的设计重点通常包括：
- 业务目标和业务能力拆分
- 领域边界划分
- 核心流程与辅助流程识别
- 核心业务与非核心业务分离
- 复用能力是否下沉为平台能力
如果以电商为例，交易、履约、支付、营销、广告、用户、商品并非一个扁平列表，而是多个不同性质的业务域。它们的稳定性要求、变化节奏和约束条件都不同。业务架构要做的，就是把这些差异先表达清楚。
业务架构图通常不会出现太多技术词。它应该回答的是：
- 平台有哪些业务模块
- 各模块之间是什么逻辑关系
- 用户和内部角色通过哪些主流程完成目标
如果一张业务架构图里充满了数据库、中间件、同步异步和并发控制，这张图大概率已经滑向了技术架构。
应用架构：把业务能力分配给应用系统
应用架构承接业务架构。业务架构告诉你平台需要哪些能力，应用架构则回答这些能力由哪些系统承接，以及系统之间如何协作。
这一层最核心的问题包括：
- 应该拆成多少应用或服务
- 各应用分别负责什么
- 应用之间通过什么边界交互
- 哪些调用应该同步，哪些应该异步
- 哪些能力要平台化，哪些能力保留在单个应用内部
应用架构既要避免大而全，也要避免碎得失控。拆分过粗，会让系统变成巨石；拆分过细，会让协作成本、调用成本和治理成本迅速上升。
一个好的应用架构通常会坚持几条原则：
- 以稳定性为中心，核心链路优先
- 核心业务和易变业务分离
- 主流程和辅助流程分离
- 跨域调用尽量解耦
- 必要同步调用要有超时、隔离和容错设计
站在图纸层面，应用架构更像系统版地图。它描述的是整个系统有哪些应用、每个应用管哪段能力、它们如何组成一条完整业务链路。
技术架构：回答系统怎么跑得稳、跑得动、跑得久
技术架构开始进入运行层。它关注的是应用系统用什么技术组件构成、如何通信、如何部署、如何满足非功能性要求。
这一层不再讨论业务应该怎么规划，而是讨论：
- 系统如何实现高可用
- 如何保证性能和扩展性
- 如何降低耦合
- 如何治理流量、故障和发布风险
- 如何通过基础设施和中间件承载上层应用
技术架构里常见的内容包括：
- 网关、负载均衡、消息队列、缓存、中间件
- 服务之间的同步和异步调用关系
- 核心链路中的数据流向
- 限流、降级、熔断、监控和告警机制
- 多机房、多活、容灾和弹性扩缩
技术架构的重点是非功能性特征。一个系统在业务上成立，并不代表它在生产环境里就能稳定运行。很多系统真正出问题，常见原因是技术架构没有为负载、故障、演进和治理留出空间。
数据架构：明确数据资产如何建模、流转和治理
很多团队会把数据架构简单理解成数据库设计，这个理解太窄了。数据架构关注的是整个系统中核心数据资产的组织方式，以及这些数据在不同应用和链路里如何流动、同步、隔离和校验。
这一层通常要回答：
- 核心数据实体有哪些
- 数据的权威源头在哪里
- 哪些场景要求强一致性，哪些可以接受最终一致性
- 数据怎么同步、备份、恢复和审计
- 应用是否可以直接访问别人的数据库
- 读写分离、分库分表、索引异构是否必要
数据架构对系统质量的影响往往比表面看上去更大。业务边界划分不清，最后通常会反映到数据职责不清；应用边界设计不稳，最后也会反映到跨库直连、重复存储和同步混乱。
一个相对稳妥的数据架构，一般会坚持这些原则：
- 统一数据视图
- 明确一致性要求和补偿策略
- 数据与应用分离
- 跨应用访问通过接口完成，不直接跨库操作
- 对高访问量和高数据量场景做读写分离与分区隔离
数据架构看似在底层，实际上对上层产品体验和系统治理都有很强约束。
代码架构：把系统设计真正落到开发者可维护的结构里
代码架构是最接近工程实现的一层。它关心的是单个应用内部的代码应该怎么组织，而不聚焦整个平台有哪些业务域，也不讨论系统部署在哪些机器上。
这里讨论的重点通常包括：
- 模块划分是否清晰
- 控制层、服务层、数据访问层职责是否明确
- 领域逻辑放在哪里
- 依赖方向是否单向
- 公共能力如何抽取
- 测试是否容易编写和维护
代码架构的目标是降低理解成本和修改成本。一个团队接手某个应用时，如果只看目录结构和模块名称，就能大致理解分层和职责，这通常说明代码架构是清晰的。
反过来，如果业务规则散落在 Controller、SQL、脚本和前端页面里，哪怕业务架构和技术架构都设计得不错，系统最终仍然会在实现层失控。
这五层架构之间是什么关系
可以把这五层理解成一条连续链路：
- 业务架构定义目标、能力和边界。
- 应用架构把这些能力分配给具体系统。
- 技术架构为这些系统提供运行和治理方式。
- 数据架构为系统之间的信息流和状态管理建立规则。
- 代码架构把单个应用内部的实现组织成可维护的结构。
从上往下看，是逐层落地；从下往上看，是逐层支撑。
这也是为什么很多架构问题不能只看一层。举个常见例子：
- 如果业务边界划错，应用怎么拆都别扭。
- 如果应用职责不清，技术架构很容易被迫用复杂中间件兜底。
- 如果数据权责不清，最终会出现跨库依赖和同步混乱。
- 如果代码架构失控，上面几层再合理，团队交付效率也会不断下降。
实际工作里最常见的几个误区
用代码问题代替业务问题
很多重构项目看起来是在改代码，根源其实是业务边界不清。系统越改越复杂，往往是因为上层业务架构没有稳定下来。
用技术组件代替应用设计
中间件、消息队列、缓存、搜索引擎都很重要，但它们不能替代应用边界设计。应用架构没有想清楚，技术组件只会把混乱放大。
用数据库表结构代替数据架构
表结构只是数据架构的一部分。数据权威源、同步机制、一致性策略、隔离策略和访问规范，才是数据架构真正的主体。
用部署图代替技术架构
部署图只是技术架构的一部分。技术架构真正关心的是系统如何实现可靠性、性能、扩展性和治理能力。
如果你要从零分析一个系统，顺序应该是什么
一个更稳妥的顺序通常是：
- 先从业务架构确认目标、角色、业务能力和主流程。
- 再从应用架构确认系统拆分和协作关系。
- 再看数据架构，明确核心实体、数据流和一致性要求。
- 然后设计技术架构，处理运行时约束和治理需求。
- 最后在单个应用内部落实代码架构。
这个顺序不意味着只能线性推进，而是提醒团队不要一上来就掉进代码和组件细节。
最后
业务架构、应用架构、技术架构、数据架构和代码架构，分别解决不同层次的问题。真正成熟的团队，会识别问题所在层次，并让这些层次之间形成清晰衔接。
如果你正在看《AI 协作》专栏，这篇附录最重要的作用，是帮你在理解 AI 系统和组织协作时保持层次感。很多看上去属于 Agent、流程或自动化的问题，往上追其实是业务和应用边界问题；往下追，又可能落到数据治理和代码结构问题。只有先分清层次，后续关于系统设计的判断才会更稳。