一文搞懂企业五大架构

你有没有算过，一套系统上线 3 年，有多少时间花在"找数据"上。

我们接触过一家制造企业，年销售额两亿多，ERP、MES、OA、CRM全上了。

财务月底对账，发现销售系统里的客户名称和 ERP 里的对不上，同一客户有"深圳腾讯"、"腾讯科技"、"深圳腾讯科技"三个条目。销售按 A 价格签的合同，财务按 B 价格开了票。

光是理清这堆数据，财务总监带着两个会计折腾了整整 4 天。

那么问题到底出在哪呢？

经过调查才发现，系统本身其实并没有什么问题，就是当初在搭建架构时，那五大架构（业务架构、应用架构、数据加固、技术架构、代码架构）没搭对，这才导致了此类问题的发生。

那架构不对，为什么会引发这些问题呢？

那对应架构的管理逻辑首先是我们要搞清楚的第一命题。

业务架构定了要管什么，应用架构定了用什么系统管，数据架构定了怎么统一口径，技术架构定了跑在什么底座上，代码架构定了程序员怎么写。这五层只要有一层没想明白，上面四层全跟着乱。

这篇文章，我们把这五层拆开讲透。每一层回答一个具体问题：这一层管什么，不管什么，和上下层怎么交接。看完你会明白，为什么那家企业花了四天对账，以及怎么避免这种事再发生。

一、业务架构，先搞清楚你到底要管什么

业务架构是起点。它不涉及任何系统、任何代码，只回答一个问题：你的业务到底怎么运转。

1、业务架构画的是价值链，不是流程图

很多人把业务架构画成流程图，第一步销售接单，第二步生产排产，第三步仓库发货。这叫业务流程，不是业务架构。

业务架构画的是能力。比如一家制造企业，核心能力可能是：市场洞察、产品研发、采购供应、生产制造、质量管控、销售渠道、售后服务。这些能力之间怎么协作，数据怎么流转，才是业务架构要表达的。

流程会变，能力相对稳定。流程是"今天怎么干"，能力是"不管怎么干，这些事总得有人做"。

2、业务架构的产出物，业务能力地图

业务能力地图通常是一张分层图。顶层是价值链，往下拆成一级能力、二级能力，直到能对应到具体部门或岗位。

举个例子。"销售渠道"这个一级能力，可以拆成：渠道规划、渠道开发、渠道运营、渠道评估。渠道运营再往下，拆成：订单处理、库存协调、物流跟踪、客户对账。

每一层都问自己：这一层的能力，由谁来承接。如果答不上来，说明拆得不够细，或者职责没分清楚。

3、业务架构的常见翻车点

最常见的翻车，是业务架构直接抄行业标杆。别人有"数字化营销"，我们也加一个。但你的企业根本没有线上获客渠道，这个能力就是虚的，挂在那里没人管，最后变成报表上的一个空壳指标。

另一个翻车点，是业务能力和 IT 系统混着谈。业务架构阶段不要想系统，只想业务。系统是用来承载能力的，能力本身和系统无关。

二、应用架构，系统之间的边界怎么划

业务架构定好了要管什么，应用架构来定用什么系统管。

1、应用架构的核心问题，一个功能放哪个系统

企业里的系统越上越多，边界越来越模糊。同一个客户信息，CRM 里有，ERP 里有，财务系统里也有。销售改了一个手机号，三个系统不同步，财务对账的时候又对不上。

应用架构要做的，就是给每个系统划清边界。这个边界和业务直接相关，技术只是实现手段。

比如客户主数据，到底归谁管。如果销售是客户的第一接触点，那 CRM 应该是客户主数据的源头。ERP 和财务系统只读，不直接改。改了必须从 CRM 同步过来。

这个规则定下来，应用架构才算完成。

2、应用架构的产出物，系统蓝图和接口关系图

系统蓝图是一张全景图，列出企业所有系统，每个系统负责哪块业务能力。接口关系图画的是系统之间怎么交互，数据从哪流向哪，谁是源头，谁是副本。

这两张图一出来，IT 部门和业务部门就有了共同语言。业务部门说"我要改客户信息"，IT 部门能立刻指出：改可以，但只能在 CRM 改，其他系统是同步过来的。

3、应用架构的常见翻车点

最大的翻车，是系统边界跟着部门边界走。销售部上 CRM，生产部上 MES，财务部上财务系统，各管各的。结果同一个数据在三个系统里存了三份，版本不一致，谁也说不清哪个是对的。

正确的做法，是按数据实体划边界。客户是一个实体，不管多少部门用，源头只能有一个。订单是一个实体，生命周期从创建到关闭，必须有一个系统全程跟踪。

三、数据架构：口径统一是底线

应用架构定了系统边界，数据架构来定数据怎么定义、怎么流转、怎么治理。

1、数据架构的核心问题，同一个东西在不同系统里叫什么

前面说的那家制造企业，客户名称对不上，就是数据架构没做好。销售系统里叫"深圳基石协作科技有限公司"，ERP 里叫"基石协作"，财务系统里叫"深圳基石"。

数据架构的第一步，是建主数据标准。客户主数据有哪些字段，每个字段什么格式，谁来维护，怎么同步，全部写清楚。

比如客户名称，统一规定是"行政区划+字号+行业+组织形式"。深圳基石协作科技有限公司，不能简写成"基石协作"，也不能漏掉"科技"。

2、数据架构的三层模型

数据架构通常分三层：概念模型、逻辑模型、物理模型。

概念模型是业务视角，定义有哪些数据实体，实体之间什么关系。比如客户和订单是一对多，一个客户可以有多个订单。

逻辑模型是系统视角，定义每个实体的属性，属性的数据类型、长度、取值范围。比如客户名称，字符串类型，长度 100，必填。

物理模型是数据库视角，定义表结构、索引、分区。这一层是 DBA 和开发关心的，业务人员不用管。

很多企业只做到了物理模型，表建好了，字段也有了，但概念模型和逻辑模型没想清楚。结果就是表结构改来改去，业务人员看不懂，开发人员也搞不清业务含义。

3、数据架构的常见翻车点

最大的翻车，是数据标准定了，但不执行。系统上线的时候为了赶进度，先跑起来再说，数据清洗后面再说。结果一拖就是三年，数据越来越乱，清洗成本越来越高。

另一个翻车点，是数据治理没有责任人。数据标准谁来维护，数据质量谁来检查，出了问题找谁，全部没定。最后变成 IT 部门背锅，但 IT 部门又改不了业务数据。

四、技术架构，底座要稳但不能过度设计

业务、应用、数据三层定好了，技术架构来搭底座。

1、技术架构的核心问题，系统跑在什么上面

技术架构包括：服务器、网络、存储、中间件、数据库、容器平台、安全体系。简单说，就是系统运行的环境。

但技术架构不是越先进越好。很多企业一上来就搞微服务、中台、云原生，结果业务还没跑顺，技术先把自己绕进去了。

技术架构的原则是：够用就好，适度超前。

2、技术架构的四层模型

技术架构通常分四层：基础设施层、平台层、数据层、应用层。

基础设施层是物理资源：服务器、网络、存储。现在大部分企业上云，这层就是云厂商提供的计算、网络、存储资源。

平台层是中间件和工具：消息队列、缓存、API 网关、容器平台。这层让开发人员不用关心底层资源，专注写业务代码。

数据层是数据库和数据处理工具：关系型数据库、NoSQL、数据仓库、实时计算。

应用层是业务系统本身，跑在平台层和数据层之上。

3、技术架构的常见翻车点

最大的翻车，是技术架构和业务需求脱节。业务部门要一个报表，技术部门说中台还没建好，等半年。结果业务部门自己用 Excel 做，数据越攒越多，最后中台建好了，也没人用。

另一个翻车点，是过度追求新技术。Kubernetes、Service Mesh、Serverless，什么火用什么。但团队没能力运维，出了问题找不到人，最后又退回传统架构。

五、代码架构：最后一公里的规范

前面四层都定好了，代码架构来规范程序员怎么写代码。

1、代码架构的核心问题，代码怎么组织才能不改一处乱全局

代码架构的重点不在写具体代码，而在定规范。分层怎么分，模块怎么划，依赖关系怎么管，全部写清楚。

常见的分层是：控制器层、服务层、领域层、数据访问层。控制器层处理 HTTP 请求，服务层处理业务逻辑，领域层封装核心业务规则，数据访问层操作数据库。

分层的好处是，改一处不会影响全局。比如数据库从 MySQL 换成 PostgreSQL，只需要改数据访问层，上面三层不用动。

2、代码架构的产出物，编码规范和脚手架

编码规范是文档，规定怎么命名、怎么注释、怎么写单元测试。脚手架是工具，一键生成项目结构，开发人员照着填代码就行。

好的代码架构，能让新入职的开发人员一周内上手，不用问老员工"这个该放哪"。

3、代码架构的常见翻车点

最大的翻车，是代码架构定了，但不执行。老项目历史包袱太重，新规范用不上。新项目一开始按规范写，但赶进度的时候又乱写，最后和遗留项目一样烂。

另一个翻车点，是代码架构和业务架构脱节。业务架构定了要支持多渠道销售，代码架构没预留扩展点，每加一个渠道就要改一堆代码。

六、五大架构怎么串起来，用一个订单串一遍

看完五层，你可能还是觉得抽象。我们用一张订单，串一遍五大架构怎么协作。

1、业务架构视角，订单属于销售渠道能力

业务架构里，订单属于"销售渠道"这个一级能力下的"订单处理"二级能力。订单的生命周期包括：创建、审核、排产、发货、签收、对账、关闭。

2、应用架构视角，订单归订单系统管

应用架构里，订单系统负责订单的全生命周期。CRM 只负责客户信息，ERP 只负责库存和财务，MES 只负责生产排产。订单系统把需求推给下游系统，但不直接操作下游系统的数据。

3、数据架构视角，订单数据标准统一

数据架构里，订单有统一的编号规则、状态定义、字段格式。订单号=日期+流水号，状态只能是：待审核、已审核、生产中、已发货、已签收、已关闭。任何系统里的订单，必须符合这个标准。

4、技术架构视角，订单系统跑在云平台上

技术架构里，订单系统部署在 Kubernetes 集群上，数据库用 MySQL 主从，缓存用 Redis，消息队列用 RabbitMQ。高峰期可以自动扩容，保证订单不丢。

5、代码架构视角，订单模块分层清晰

代码架构里，订单模块分四层。控制器层接收下单请求，服务层处理下单逻辑，领域层封装订单状态机，数据访问层操作订单表。加一个新订单类型，只需要在领域层加状态流转规则，其他层不用改。

一张订单从创建到关闭，五大架构层层接力。任何一层出问题，订单就会卡在那里。

七、架构落地的三个原则

五大架构听起来很宏大，落地的时候记住三个原则。

1、从上到下设计，从下到上验证

设计的时候，先业务后应用再数据再技术最后代码。验证的时候反过来，代码能不能跑通，技术能不能支撑，数据能不能对齐，应用能不能承载，最后业务目标有没有达成。

2、架构是演进的，不是一蹴而就的

不要指望一次性把五大架构都定完美。业务在变，技术在变，架构也要跟着变。但每一层变的时候，要清楚对上下层的影响。

3、架构文档要活，不要死

架构图不是画完就挂墙上。每次系统变更，都要更新架构文档。文档过时了，比没有文档还害人。

八、低代码怎么加速架构落地？

五大架构定好了，落地的时候还有一个问题：传统开发太慢。

业务架构定了要加一个"渠道返利"能力，应用架构定了放在订单系统里，数据架构定了返利计算规则，技术架构定了跑在现有平台上，代码架构定了分层规范。按传统开发，从需求到上线至少两个月。

用低代码平台，可以把周期缩短到两周。业务人员用可视化工具搭返利计算逻辑，IT 人员做数据对接和权限配置，开发人员在关键节点写脚本扩展。

织信Informat 这类企业级低代码平台，支持从业务建模到应用发布的全流程。业务架构的能力地图可以直接转成数据模型，应用架构的系统边界可以用 API 网关管理，数据架构的主数据标准可以用内置的数据治理工具维护。

低代码有它的边界。技术架构里的基础设施、代码架构里的复杂算法，还是需要专业开发人员。五大架构里偏上层的部分，低代码可以显著加速。

如果你正在梳理企业架构，想快速验证某个业务能力的可行性，可以在织信Informat 上搭一个原型试试。https://www.informat.cn/?from=tth1082101

结束语

五大架构构成从业务到代码的完整链条。业务架构定方向，应用架构划边界，数据架构统一口径，技术架构搭底座，代码架构做实现。

我们不难发现：架构混乱的根源，往往是某一层没想清楚就往下走。业务还没理清楚就上系统，系统边界还没划清楚就建数据标准，数据标准还没定清楚就写代码。每一层的债，都会变成下一层的坑。

那家企业花了四天对账，表面是数据不一致，根子是五大架构没搭对。销售、ERP、财务三个系统各自为政，数据没有统一源头，没有同步机制，没有责任人。修数据只用了四天，但理清架构、重建标准、改造系统，用了整整六个月。

架构这件事，前期多花一周想清楚，后期能省半年折腾。这笔账，值得好好算一算。