企业总体架构实战：从业务模型到SOA落地的124页避坑指南

简介：这份PDF文档围绕企业总体架构展开，面向架构师、技术负责人及中高级研发人员，系统讲解业务架构、应用架构、数据架构与技术架构四大领域的定位与协作关系，帮助读者理解如何用架构规划解决系统故障频发、运维困难等实际问题。资源共1个PDF文件，压缩包约615KB，内容以图文结合方式呈现，涵盖商务模型、功能与应用架构、E-R图与数据状态图、物理部署及领域模型、架构规划等模块，并附有目录结构便于按章节查阅。文档源自作者为一家拥有200位研发人员、200多台服务器的公司撰写的124页架构改造方案，直接指导了后续技术改造，读者可从中获取从现状诊断到中远期规划、从业务建模到服务化拆分的完整思路与落地参考。目前已有3434人学习下载，适合需要系统梳理企业架构方法论、对照案例查漏补缺的技术人员。

1. 从 200 人研发团队的系统崩盘说起：企业总体架构到底救什么火

如果你所在的公司研发过百人、服务器过两百台，却还在靠“重启大法”和“加机器”扛故障，那这套东西你迟早得补。我当时进那家公司，系统已经处于“玩不下去”的状态：日常发布必出故障，访问量稍微一冲就雪崩，最要命的是——找不到根因。运维说是应用写得烂，应用说是数据库扛不住，数据库说是网络抖，一圈踢皮球下来，没人能拍板。后来我花了一个半月，写了份 124 页的企业总体架构文档，把业务架构、应用架构、数据架构和技术架构四条线一次性拉通，才把技术改造的方向定死。这份资料不是讲概念的书，它是一份可以直接照着拆解自家系统的实操底稿，适合研发负责人、架构师、技术经理，以及被“系统越改越乱”折磨过的后端老兵。

2. 业务架构怎么落笔：从商务模型到业务流程的拆解顺序

很多人一上来就画应用架构图，这是典型的翻车起手式。应用是给业务服务的，业务没理清，应用架构画得再漂亮也是空中楼阁。这份文档的第一个大块就是企业商务模型，它的作用是把“公司怎么赚钱”这件事翻译成技术能看懂的语言。

2.1 商务模型七件套：主营业务、模式、主体、竞品、组织、运作、流程

商务模型不是写给自己看的抒情文，它要能直接推导出系统边界。文档里把它拆成七块：主营业务（做什么）、商业模式（怎么赚钱）、商务主体（谁在做）、竞品分析（对手什么情况）、组织架构（部门怎么分、各多少人）、商务运作模型（钱怎么转一圈）、业务流程（预订、订单处理、产品供应、财务结算、账户管理）。

这里面最容易被忽略、但价值最高的是组织架构图带人数。把部门人数和系统模块的调用关系叠在一起看，你立刻能判断出哪些模块是高频核心、哪些是边缘长尾。比如某部门 50 人天天用订单模块，那这个模块的复杂度、稳定性优先级就得拉满；某个只有 3 人用的报表模块，就别浪费架构资源。

商务运作模型可以理解成一台机器：售前做计划 → 采购进货 → 服务结算 → 卖给经销商和采购商 → 赚利润 → 售后做数据分析 → 反过来指导售前。这个闭环画出来，你就知道数据在哪些环节产生、在哪些环节被消费，后面做数据架构时直接对应。

提示：业务流程至少要把预订流程、订单处理流程、产品供应流程、财务结算流程、账户管理流程这五条画出来，它们是后面 SOA 服务划分的直接依据。

2.2 从业务流程图到领域模型的映射方法

业务流程图是对业务操作的抽象，领域模型是对业务逻辑代码的抽象，两者有参考对应关系，但不是一对一。文档里的做法是：先建领域词汇表，统一概念，减少“一词多义、一义多词”。概念定了，再挂属性和行为，然后作为一个单元去和其他事物构建关系，模型自然就出来了。

领域模型在实现时可大可小：业务早期系统小，它可能就是一个类；系统做大了，它可能是一个 DLL 库；再大一点，它就是一个服务，给不同应用调用。每一个方法都有成为服务的潜质，尤其在系统中后期。这句话是整份文档里我最认同的判断之一，它解释了为什么后面要做 SOA 规划。

具体操作上，我一般会按这个顺序走：

1. 拉出业务流程清单，每条流程标注涉及的角色和数据实体；
2. 对每个数据实体建词汇卡，写清定义、别名、生命周期；
3. 把流程中的动作映射成领域行为，标注哪些行为被多个流程复用；
4. 复用度高的行为，单独抽出来作为候选服务。

这套动作做完，领域模型基本就稳了，而且它相对稳定——业务模型不变，高层领域模型就不该频繁变。

3. 应用架构与数据架构：接口复用和 E-R 图怎么画才不白画

现状梳理是整份文档里最耗时的部分，但也是最不能跳的。你连现在有什么都不知道，规划就是拍脑袋。文档把现状分成四块：功能架构、应用架构、数据设计、物理架构。这一章重点讲前两块里最容易做错的地方。

3.1 功能架构三要素：功能、角色、权限的对应关系

功能架构就三样东西：功能、角色、权限。功能是企业服务，用户用的每一个功能就是企业的一个服务；角色是用户操作的归类；功能与角色的对应关系就是权限。

听起来简单，但很多公司这三样是散的：功能列表在需求文档里，角色在权限系统里，权限配置在运维手里，三边对不上。文档的做法是把它们画在一张图上，一眼就能看出哪个角色拥有哪些功能、哪些功能没人用、哪些权限给大了。

注意：功能架构梳理时，不要按部门去对功能，要按角色去对。部门会变，角色相对稳定。

3.2 应用架构的核心：接口复用度与业务逻辑独立存在

应用架构部分包括现有架构图、Web 应用现状、Job 作业小应用现状、接口架构。其中接口是应用层面的关键，它是一个程序与另一个程序交互的部分。

文档里有个判断非常犀利：应用架构图要标出哪些业务逻辑没有被重用。换句话说，一个业务逻辑被多少个应用调用，就需要被重复开发多少次；一旦改了一个地方，就要同时改多个地方，开发效率极低。

这里要建立一个认知：业务逻辑可以独立存在，也可以寄宿于多个应用。比如预订逻辑，被多个应用调用，但它和应用本身没有从属关系。业务逻辑是业务操作的抽象，业务应用与业务部门共同完成业务操作。把这个关系理清，你才知道哪些逻辑该抽成服务、哪些该留在应用里。

我一般会做一张接口复用矩阵表：

复用次数大于等于 2 的，基本都可以进入 SOA 规划候选名单。这张表不需要多漂亮，Excel 就能做，关键是逼着团队把“到底重复了多少”这件事量化出来。

3.3 数据设计：100 多个库、一万多张表怎么收进一张 E-R 图

这是整份文档里最反直觉的一段。100 多个数据库、一万多张表，能不能用一张 E-R 图表示？文档的答案是：可以。关键在于——数据设计依赖于企业的数据，而不是数据库的设计。

做法是：对企业数据做归类，归类直接导致数据设计，最终画出 E-R 图；E-R 图出来后，数据库设计自然就出来了。超越库、超越表去看这张图，它包含五类数据：产品、订单、结算、用户、基础设施。

这里有个非常重要的分层判断：低层 E-R 图可以变，高层 E-R 图一般不变，因为高层 E-R 图是根据业务模型定的，业务模型稳定，高层 E-R 图就稳定。数据库只要早期设计得好，是可以做到易伸缩、易拆分的。

文档里那张从内往外看的图很值得琢磨：一个框既可以是一个库，也可以是一个模块，还可以是一个表。业务早期它是一个库，里面有 5 个模块；中期可以拆成 5 个库；后期可以拆成更多库。拆不拆、什么时候拆，取决于业务阶段和系统复杂度，而不是取决于数据库当前有多卡。

除了静态 E-R 图，还要画数据状态图，也就是数据的流转状态。比如国内订单状态变迁：等待支付 → 支付成功 / 超时关闭。从等待支付到支付成功中间有个“支付行为”，这个行为把数据状态变更为支付成功，否则继续等待直到超时。这个支付行为可以做成一个微服务，由不同应用调用。状态图的价值不仅在数据库层，更在服务化——每一个状态变迁动作，都是一个潜在的服务边界。

4. 技术架构与物理架构：200 台服务器 8 个机房的血泪教训

技术架构这块，文档里叫物理架构，内容包括 IDC 机房、机房之间访问关系、机房内服务器物理部署图、机房与业务分布、网站架构、数据库架构、集群清单、域名清单。把这些用列表和图形整理出来，问题会自己浮出来。

4.1 物理架构不合理，应用架构不可能合理

案例里那家公司有 5 个地区、8 个机房，服务器才 200 多台，但分布极散，物理结构复杂，通讯也复杂。技改前故障不断，一个主要原因就是物理架构不合理。文档里有个非常直接的判断：运维要占 60% 到 70% 的责任，但当时却把责任归咎为应用架构，这是错误的方向。

原因很简单：物理架构是最底层的基础设施，下层为上层服务。运维要为应用服务，应用要为业务服务，业务要为客人服务。物理架构不合理，应用架构很难合理。这个顺序不能倒过来想。

我一般会先拉一张机房与业务分布表：

跨机房调用多、又有单点的，就是优先要动刀的地方。这张表比任何架构图都更能说服老板批预算。

4.2 集群规划与域名规划：20 倍规划、5 倍设计、1.5 倍实施

物理规划分两块：集群规划和域名规划。

集群规划有个口诀：20 倍规划、5 倍设计和 1.5 倍实施。规划和设计要大一些，实施时小一些，既便于将来扩展，又节省当前费用。两个逻辑网络（内网、外网），两个负载均衡，两个防火墙，安全隔离内外网。四条产品线：国际、国内、新业务、公共业务。六个集群：Web 集群、SOA 集群、中间件集群、数据库集群、Job 集群、ITD 集群。横向集群与纵向产品线形成一个矩阵结构，网络基础架构基本就定了。

域名规划的原则是：对内的域名该改的改、该停用的停用、该合并的合并；对外的域名尽量少改，要改也要有历史继承性（比如跳转），尽量减小对用户的影响。

提示：域名规划最容易被当成运维杂事，但它直接影响用户感知和 SEO，对外域名变更必须走评审。

4.3 分层架构选型：领域架构和三层架构到底差在哪

文档里对比了两种分层架构。一种是领域架构：仓储层、领域层、应用服务层、表现层、基础公共层。另一种是传统三层：数据层、应用逻辑层、表现层。

两者的区别，文档的判断是：早期做三层架构大多以表来驱动，做领域架构大多以业务逻辑来驱动。但到了现在，如果都以业务逻辑为中心，实际上两者并没有本质区别。

案例公司选了第二种分层法，理由是希望分层极简，哪怕刚毕业进来的员工在分层时基本也不会乱。这个选择背后的逻辑值得记住：分层越简单，软件结构越清晰，代码越容易统一。把工程做得极简，才有利于复制、有利于业务快速构建、有利于规模化。

还有一个配套原则：每一个应用的代码量都不应该很大，一旦工程变得过大，就适当拆分，而不是全部塞在一个单块应用里。

5. 架构规划与实施避坑：从 SOA 服务划分到 Roadmap 分步落地

规划和实施是两份事，但坑往往连在一起。这一章把 SOA 规划、数据库规划、架构实施里的常见问题集中讲清楚。

5.1 SOA 规划：五个服务中心怎么从业务流程推出来

SOA 规划就是接口规划，它的归类与商务模型中的业务流程有参考对应关系。案例里有五个服务中心：预订服务、订单处理服务、产品供应服务、财务结算服务、公共服务。每个服务只需要实现一套自己的逻辑，前台、后台、接口、Job 小应用都可以调用。修改代码时只需要改一个地方，就能影响所有调用这个服务的前端应用。

服务划分不是拍脑袋，是从业务流程归类和接口复用矩阵推出来的。业务流程有哪几条主链，服务就大致有哪几个中心；接口复用矩阵里复用次数高的逻辑，就优先抽成服务。

5.2 数据库规划：为什么要提前两步建库

数据库是整个信息系统中生命周期最长、最难修改的部分。文档的建议是：数据库设计至少要提前两步，根据高层 E-R 图和数据设计来新建数据库，早建比晚建好。

数据库调整代价大、周期长，长时间产生的问题需要长时间解决。策略是：先在新库里解决新表，再根据当前业务和应用的需求，逐步调整旧表。不要指望一次性重构完，那是给自己挖坑。

5.3 架构实施避坑：五条踩坑记录

现象一：故障频发，但团队一致认为是应用代码烂。原因：物理架构分散、跨机房调用复杂，底层不稳，上层怎么优化都白搭。 解决：先拉机房与业务分布表，定位单点和跨机房调用，物理架构先动刀，再谈应用重构。

现象二：同一个业务逻辑改了五六个地方，还漏改。原因：业务逻辑没有独立存在，寄宿在多个应用里，重复开发。 解决：建接口复用矩阵，复用次数大于等于 2 的逻辑抽成服务，统一入口。

现象三：数据库越拆越乱，拆完发现关联查询全废了。原因：按数据库当前性能拆，而不是按企业数据分类拆。 解决：先画高层 E-R 图，按产品、订单、结算、用户、基础设施五类数据归类，再决定拆库节奏。

现象四：分层架构推不动，新老员工各写各的。原因：分层太复杂，或者没有统一的分层规范。 解决：选极简分层，配套代码评审，工程过大就拆，不搞单块巨无霸。

现象五：技术改造推一期停一期，业务部门不配合。原因：技改和业务研发两张皮，技改没有业务价值输出。 解决：技改即是工单、工单即是技改，把技改嵌进业务研发项目里，Roadmap 近细远粗、分步实施。

6. 一份 124 页文档的复用技巧：从 TOGAF 对照到新员工快速上手

这份文档写完很久之后，我才知道有 TOGAF 这个标准。对照下来，TOGAF 的内容主要包括业务架构、应用架构、数据架构和技术架构，而我们当时只是以解决公司系统架构问题为导向、以时间为主线，内容是企业商务模型、架构现状、领域模型、架构规划、架构实施。两者有很多相似，也有不同。相似的是四条线的划分逻辑，不同的是我们是从问题出发倒推，不是从标准框架正推。

如果你要复用这份资料，我的建议是不要照抄目录，而是按这个顺序走一遍：

这份文档还有一个被低估的价值：把隐性知识显性化。对新员工来说，它是快速入门的全局图；对老员工来说，它是了解全局、梳理过程、然后专注自己那部分的参照系。Big Picture 的作用不是好看，是让所有人知道自己在哪、要去哪。

从那以后，我每次接手一个烂摊子系统，都强制自己先走一遍“业务模型 → 现状梳理 → 领域模型 → 规划 → 实施”这条线，哪怕时间紧，也要先把业务流程图和接口复用矩阵拉出来。没有这两样，后面的架构决策全是玄学。希望这份 124 页文档的拆解思路，能帮到你。

本文还有配套的精品资源，点击获取