企业官网建设流程全解析

聊“软件架构模式”这件事，我一直觉得比聊具体框架要难得多。框架有文档、有版本号、有社区问答，架构模式没有——它更像一门关于“取舍”的手艺。前阵子帮一个做内部管理系统的团队看代码，五个人维护，却把服务拆成了十一个，每次改一个审批流字段要发六次版，本地环境跑不起来，联调靠人肉对表。他们问我该补哪个中间件，我说先别补，你这不是技术问题，是架构模式选错了。这类情况我见过太多次：大家把架构模式当成“高级感”的标签，而不是解决问题的工具。这篇文章想干的事情很朴素——把常见的软件架构模式挨个掰开，讲清楚它解决什么、代价是什么、什么场景下值得上、什么场景下上了就是给自己挖坑，并且给出能直接抄作业的目录结构、接口约定和排查思路。不管你是刚接手第一个模块的新人，还是要为几十人团队定技术方向的老手，都能在这里找到对得上的那一段。

1. 架构模式到底在解决什么问题

1.1 先把“模式”和“框架”分开看

很多人一上来就把架构模式和框架混为一谈，觉得用了某个依赖注入容器、某个 Web 框架，架构就自动变好了。这两者的关系应该这么理解：框架是“已经写好的零件”，架构模式是“这些零件怎么摆、线怎么走、出问题了从哪一节开始查”。零件可以随时换，走线方式一旦定错，换零件是救不回来的——我见过把缓存组件从 A 换到 B 换了三轮、接口响应依旧慢成狗的团队，最后发现根因是业务逻辑全堆在控制器里，每次请求要串行查七次数据库，换什么缓存都白搭。

所以判断一个架构模式值不值得用，我一般看三个东西：它是否降低了某类变更的成本、它是否把某类故障的影响范围收窄了、它引入的额外复杂度是不是团队当前能扛住的。三条里至少占两条，才考虑落地。比如分层架构降低了“换存储实现”的成本，事件驱动收窄了“单个下游挂掉”的影响范围，而微服务把前两条都占了，但同时把运维复杂度拉高了两个数量级——小团队扛不住，就是负收益。

1.2 三个决定选型的关键变量

在我自己的经验里，选架构模式前必须问清楚三件事，这三件事基本能把方案筛掉一大半。

第一是变更频率的分布。如果整个系统的需求变更集中在少数几个模块，那么模块化的单体远好过分布式拆分，因为你根本不需要为“低频模块”付出网络调用的代价。反过来，如果十几个业务域每周都在各自迭代，互相之间抢发布窗口，那拆分的必要性就上来了。

第二是团队规模与协作半径。架构模式的本质之一是“组织沟通结构的投影”。三个人做一个系统，代码在一个仓库、一次构建、一次部署，沟通成本几乎为零，强行拆成多仓库多服务，只是把人和人的沟通问题变成了进程和进程的通信问题，反而更贵。等到三十个人以上、分成五六个小组，一个仓库的合并冲突和构建排队就会变成主要矛盾，这时边界清晰的服务拆分才划算。

第三是一致性要求的刚性程度。账务、库存扣减这类场景对强一致的要求是硬的，跨服务搞柔性事务会用复杂度换一点可用性，值不值要算清楚；而内容展示、日志统计、消息推送这类场景，最终一致完全够用，事件驱动就是更优解。

把这三个变量填进一张表里，其实选型结论往往就浮出来了：

1.3 别忽略“团队熟悉度”这个隐藏变量

上面三个变量之外，还有一个特别现实的因素：团队对这个模式熟不熟。一个从没接触过事件驱动的团队，第一次上异步链路，最常见的结局是把消息重复消费写出资损，然后整个团队对异步产生心理阴影。这种情况下，哪怕场景确实更适合异步，我也会建议先用同步调用把业务跑通，留好接口抽象，等团队补齐了对幂等、重试、死信的理解，再逐步切换。

架构演进最忌讳的就是一步到位。我自己的做法是“小步换轮子”：先用最笨但最可控的方式实现，把边界和接口定清楚，等某一条边界确实成了瓶颈，再把那一段换成更复杂的模式。这样每一次改动的影响范围都可控，出问题也能快速回退。

2. 分层架构与MVC：最熟的那一套为什么还在用

2.1 分层的本质是“依赖方向管理”

分层架构被讲烂了，但讲清楚它“为什么必须这么分”的人不多。核心只有一句话：依赖只能单向流动，内层不知道外层的存在。展示层依赖应用层，应用层依赖领域层，领域层谁都不依赖——这才叫分层。如果你的实体对象里 import 了数据库访问类，那就不叫分层，只是把代码分了文件夹。

我常用一个类比向新人解释：分层就像做菜。厨房（领域层）只管按菜谱做菜，不关心菜是堂食还是外卖；服务员（应用层）负责把订单翻译成厨房能懂的指令，并决定先做哪道；前台（展示层）只负责跟客人打交道。如果厨房开始关心“这盘菜是给 3 号桌还是外卖骑手”，菜谱就会被迫频繁改动，一出问题所有桌都受影响。现实中最常见的腐化就是“厨房关心前台”——业务逻辑里塞了 HTTP 请求对象、塞了页面字段名，导致同一个业务能力没法被第二处调用。

具体到落地，我会把分层切成严格四层，并且明确规定跨层调用规则：

src/ interfaces/ # 控制器、消息消费者、定时任务入口 http/ mq/ application/ # 用例编排、事务边界、权限校验 usecase/ domain/ # 实体、值对象、领域服务、仓储接口 model/ service/ repository/ # 只有接口，没有实现 infrastructure/ # 仓储实现、外部调用适配、缓存、ORM 映射 persistence/ client/

关键约定有三个：领域层定义的仓储只有接口，实现放在基础设施层，靠依赖注入在启动时装配；应用层负责事务边界，领域层不写事务注解；展示层的入参对象不允许穿透到领域层，必须在应用层完成转换。这三条守住，换数据库、加缓存、加第二个入口（比如再挂一个消息消费者调同一个用例）都不用改业务代码。

2.2 MVC的三种变形，别混着用

MVC 是最容易被讲乱的一个。它在不同场景下其实是三个不同的东西：

服务端渲染场景里，M 是领域数据，V 是模板，C 是路由加参数绑定，控制器尽量薄，只做校验和转发。这时候最容易出的问题是控制器里堆业务，导致“胖控制器”。

前后端分离场景里，MVC 中的 V 移到了浏览器，服务端实际变成了“控制器 + 应用服务 + 领域”的三段式，所谓的前端 MVC 反而变成了前端自己的状态管理问题。这时候如果还按服务端渲染的思路组织后端代码，就会写出大量只做数据搬运的 DTO 转换层，徒增维护成本。

客户端/桌面应用场景里，常见的是 MVVM，VM 负责把模型数据映射成视图状态。这里的头条禁忌是“视图直接改模型”——一旦双向绑定被滥用，数据流向就不可追踪了，出现界面和数据不一致时只能靠打印日志猜。

我个人的取舍原则是：只要一个控制器方法超过 15 行、或者出现了第二个分支判断业务规则，就把逻辑往下推到应用层。控制器永远只做四件事：取参数、校验参数格式、调用例、包装响应。这条规则执行半年，控制器层的 bug 率能明显下降，因为它的表面积被压到最小了。

2.3 分层腐化的三个典型信号

分层架构不会突然崩，它是慢慢烂的。我总结了三个可以当成预警灯的信号：

信号一：实体对象带上了持久化注解和序列化注解。这说明领域模型被迫同时服务数据库和接口协议，一旦接口字段要改，数据库映射也要跟着动。解法是拆成领域实体、持久化对象、接口传输对象三套，中间用转换器衔接——多写一点映射代码，换来的是三条链路的独立演化。

信号二：出现了“工具类大杂烩”包。当utils包里塞了日期处理、金额计算、权限判断、字符串拼装，说明边界已经失效，大家都不知道代码该往哪放。金额计算这类跟业务强相关的逻辑，应该进领域服务，而不是躺在工具类里被各处随意调用。

信号三：循环依赖。A 服务的实现里调 B，B 的实现里又调 A，编译能过（因为都是类级别引用），运行时靠延迟加载勉强活着，测试一跑就炸。解法通常不是加接口，而是承认这两个东西属于同一个聚合，要么合并，要么把共用部分下沉到更内层。

注意：分层不是层数越多越好。我见过分七层的项目，一次查询要穿过七个对象，改一个字段要动七个文件。四层基本够用，特殊场景最多五层，超出的层往往是在为“将来可能的需求”买单。

3. 模块化单体：被低估的性价比之王

3.1 什么情况下千万别急着拆服务

开头提到的那个十一个服务的团队，我给他们算过一笔账：十一个服务意味着至少十一套构建流水线、十一份配置、一套服务发现、一套链路追踪、一套日志聚合，还得有人值守发布。五个人分摊下来，每个人有接近一半的精力花在“让系统能跑起来”上，而不是做业务。这个成本在小团队里是致命的。

模块化单体就是针对这种情况的方案：一个进程、一次部署，但内部按业务域切成互不越界的模块。它的好处是显而易见的——调试可以单步走完整个调用链，事务是本地事务不用考虑补偿，本地启动一次就能跑全流程。而它需要付出的代价，是在代码层面严格执行边界纪律，因为没有网络边界帮你兜底。

判断要不要拆，我一般用“发布冲突频率”当指标：连续三个月，如果同一个仓库里每周都出现因为不同业务线互相阻塞发布的情况，那说明模块边界已经撑不住了；如果三个月里冲突次数不到五次，拆分带来的收益根本覆盖不了运维成本。

3.2 模块化的具体落地手法

落地模块化单体，光有目录不够，得有四道“物理隔离”：

第一道是模块内自包含。每个模块有自己的控制器、应用服务、领域模型、仓储实现，甚至自己的数据库表前缀。跨模块只能调对方暴露的 façade 接口，不能直接引用对方的实体。

src/ modules/ order/ api/ # 对外暴露的接口定义（其他模块只允许依赖这里） OrderFacade OrderCreatedEvent internal/ # 模块内部实现，外部禁止引用 application/ domain/ infrastructure/ inventory/ api/ internal/ billing/ api/ internal/ shared/ # 只放真正的通用能力：ID生成、时间、金额类型

第二道是依赖方向校验。靠人自觉是靠不住的，得让构建过程帮你检查。最简单的方式是写一个依赖检查脚本，扫描各模块internal包的引用关系，发现跨模块引用internal就直接让构建失败。工具链成熟的团队可以用架构守护测试，把这个规则写成单测，每次提交都跑。

第三道是数据表按模块切分。订单模块不允许直接 join 库存模块的表，需要的数据通过 façade 接口拿，或者订阅对方的事件在本地保存一份冗余。这条一开始会很别扭，但它是未来能不能平滑拆服务的关键——如果表都缠在一起，将来拆的时候得先做一轮痛苦的数据解耦。

第四道是事件解耦耗时操作。下单成功后要发通知、加积分、写统计，这些不该阻塞主链路。用一个进程内的事件总线（也可以先落本地消息表再异步投递）把主流程和旁路流程分开，将来要拆服务时，把进程内总线换成消息中间件即可，业务代码几乎不动。

3.3 怎么验证模块边界是有效的

有个很朴素的办法：试着把某个模块单独打包出去，看能不能编译通过。如果一抽就带出一大串依赖，说明边界是假的。第二个办法是看目录树里有没有出现“跨模块共享实体”的迹象，比如订单模块和库存模块共用一个Product实体——这个实体应该归属于商品模块，其他模块只拿它需要的字段（比如商品的 ID 和名称快照），而不是拿整个对象。

第三个办法比较狠：让新来的同事只改一个模块的功能，看他需要读多少个目录的代码。如果改个订单折扣要读五个模块，说明边界划分有问题。

4. 微服务与事件驱动：拆完之后的新麻烦

4.1 拆分粒度的判断标准

微服务的粒度是被问得最多的问题。我的判断标准从来不是“代码行数”或者“团队人数”，而是变更的同频性：会一起变的东西放在一起，不会一起变的东西分开。订单和支付如果每次需求都是一起改、一起测、一起上，那拆开就是给自己找麻烦。而订单和推荐如果一年都不需要同时改，拆开就很自然。

另一个视角是故障隔离需求。推荐服务挂了不能让下单挂掉，这种需求就足以支撑拆分。反过来，两个模块挂了一个另一个也基本没意义，那就没必要拆。

还有一个容易被忽略的点：数据归属清晰度。如果一个服务的数据必须依赖另一个服务的表才能算出来，说明这两个服务之间的边界是错的，强行拆开只会制造大量跨服务查询。这类情况我一般建议先合回去，等数据归属理清楚了再拆。

4.2 事件驱动：省了耦合，欠了确定性

事件驱动的核心价值是把“调用方必须知道被调方”变成“调用方只广播事实”。订单服务发一个“订单已创建”，积分、通知、统计各自订阅，订单服务完全不关心谁在听。新增一个下游时，订单服务一行代码都不用改，这是同步调用做不到的。

但它欠下的债也很实在。第一笔债是最终一致：事件从发出到被消费之间，系统处于中间态。用户在订单页看到已创建，去积分页可能暂时没到账。这个体验问题必须在产品层面对齐，比如前端做“积分稍后到账”的提示，而不是等后端补偿。

第二笔债是重复与乱序。消息中间件大多保证至少一次投递，重复消费是常态，所以每个消费者都必须做幂等——用业务唯一键（订单号 + 事件类型）落一张去重表，或者用状态机约束“只能从待支付到已支付”。乱序更麻烦，同一个订单的创建和取消事件如果反序到达，结果就错了。解法一般是按业务主键做分区，保证同一个键的事件进同一个分区，串行消费。

第三笔债是排查难度。同步调用出错，栈里一眼看到哪一层挂了；异步出错，你只知道“积分没到账”，得从生产者日志、中间件堆积、消费者日志三段去拼。所以上事件驱动之前，必须先有链路追踪和统一的 traceId 透传，否则后面全是黑盒。

4.3 同步还是异步，用这张表对照着选

我自己的经验线是：主链路（用户点击后要立刻看到结果的那条）尽量保持同步、保持短；所有“事后才需要”的动作一律异步。这条线划清楚，系统的响应时间和故障半径都能明显改善。

5. 管道过滤器、CQRS与六边形：被误读的三个模式

5.1 管道过滤器：处理流程固定时的最佳解

管道过滤器的模型特别简单：数据从一头进，穿过一串联的处理器，每个处理器只做一件独立的事，处理完交给下一个。它的适用场景是流程固定、每一步职责单一、需要灵活组合。典型的像文件处理链路（解密、解压、解析、清洗、入库）、请求过滤链（鉴权、限流、参数校验、日志）、数据同步链路（抽取、转换、加载）。

它最大的好处是每个过滤器可以单独测试、单独替换、单独排序。我做过一个日志解析需求，一开始全写在一个三百行的方法里，需求一改就得重读整段代码；后来拆成七个过滤器，每个不到四十行，新增一种格式只需要在末尾插一个过滤器，不影响已有的。

代价是要注意两点：一是中间数据格式要定好，否则过滤器之间会互相污染；二是错误处理策略要统一，是遇错终止还是跳过记录，必须提前约定，否则上游认为失败下游认为成功。

5.2 CQRS：读写分离的架构级表达

CQRS 常被误认为就是“主从库读写分离”。其实读写分离是它的实现手段之一，CQRS 的本质是在模型层面把命令和查询分开：写模型负责校验业务规则、维护一致性，读模型负责高效组装展示数据。写模型的表设计追求规范化，读模型可以为每个页面单独建宽表或者视图。

什么时候值得上？我总结出两个触发条件：一是读写比例悬殊且查询形态多样，比如一个后台系统，写入很少但列表页有十几种筛选组合和排序方式，用一套模型硬扛会导致 SQL 越写越复杂；二是写侧有复杂的一致性校验，如果读侧也走同一套领域模型，性能和代码可读性都会受影响。

但要提醒一句：CQRS 会让“写完之后读不到”变成一个真实的坑——写模型落库到读模型同步之间有时间差，用户提交表单后立刻刷新列表可能看不到自己刚提交的数据。常见解法是写入后返回数据版本号，前端在同步完成前做特殊提示，或者让当前用户看到自己未同步的数据。这些都是产品交互问题，不解决，技术方案就落不了地。

5.3 六边形架构：把外部世界全部挡在门外

六边形架构（也叫端口适配器）解决的是一个很具体的痛点：业务逻辑被外部依赖绑架。数据库、消息中间件、第三方接口、定时任务，这些东西一换就牵一发动全身。它的做法是把核心业务放在中间，对外只定义“端口”（一组接口），由“适配器”去实现——数据库适配器、HTTP 适配器、消息适配器都只是端口的实现。

落到代码上就是一句话：领域层只依赖自己定义的接口，不依赖任何外部库。仓储接口写在领域层，实现写在适配器层；第三方支付只暴露一个支付端口，具体厂商的报文转换全在适配器里做。这样换供应商、加第二套实现、在测试里用内存实现替换真实数据库，都不需要动核心逻辑。

六边形架构和分层架构并不冲突，它更像是分层的加强版——把“基础设施层”明确成一组可插拔的适配器，并且强调端口由内层定义而不是外层定义。实际项目里我把两者揉在一起用：分层负责纵向结构，端口适配器负责横向外设。

6. 常见问题与排查技巧实录

6.1 架构层面的问题速查表

6.2 几个踩过才知道的技巧

第一个技巧：先画调用链再画部署图。很多人设计架构时直接画部署图（几个服务、几个库），但真正决定代码好不好维护的是调用链。拿一张纸，把“用户点下单”这条链上从入口到落库的所有调用按顺序写出来，如果超过十跳，基本可以判断链路过长，需要合并或异步化。

第二个技巧：给每个跨边界调用加一层防腐层。不管是跨模块还是跨服务，调用方一定要有自己的转换层，把对方的模型转成自己的模型。这层看着冗余，但对方改字段时你只需要改一个转换器，而不是全仓库搜索。

第三个技巧：架构决策要写下来。我当时吃过一次亏，团队决定用异步事件替代同步调用，半年后新来的人不知道为什么不用直接调用，又加回去了，结果引入了两套逻辑并存。后来我们养成习惯，每个重要决策写一小段记录：背景、考虑过的方案、为什么这么选、什么条件下应该重新评估。这比任何文档都管用。

第四个技巧：给架构加“可回退点”。每次结构调整都以能回退为前提：新链路先双写、先并行跑一段时间对比结果，确认无误再切主。老链路保留一个版本周期再删。这个习惯能让你在架构演进时心态稳很多。

7. 演进路线：从单体到分布式的分阶段落地

7.1 分四个阶段推进，每阶段都有验收标准

我一般把架构演进拆成四个阶段，每个阶段都有明确的验收标准，不达标就不进下一阶段。

阶段一：把分层做扎实。目标是业务逻辑与框架解耦，验收标准是“把 Web 层整个删掉，领域层仍能编译并通过单元测试”。这一步做好了，后面所有演进都有了基础。

阶段二：模块化单体。按业务域切模块，验收标准是“任意模块可以独立编译，跨模块只依赖 façade 接口”。这一步做完，其实已经拿到了大部分拆分收益，而且没有分布式成本。

阶段三：抽离高负载或高频变更模块。只挑真正需要的模块拆成独立服务，通常是读多写少的查询服务、或者迭代节奏完全不同的业务域。验收标准是“拆分后主链路响应时间不上升，故障影响范围可界定”。

阶段四：引入异步与读模型。在链路稳定之后，把旁路逻辑异步化，针对复杂查询建读模型。验收标准是“消息堆积有监控告警，日终对账能自动发现不一致”。

7.2 迁移期最实用的手法：双写与影子流量

从旧结构迁到新结构，最怕的是“一把切换、出事回不去”。我的常规做法是双写加对比：新链路和老链路同时执行，两边结果落库后做差异比对，差异率降到可接受范围再切流。对查询类改动，可以用影子流量——把真实请求复制一份打到新链路上，只记录结果不返回给用户，跑一周看错误率和耗时。

这套手法的成本是短期的资源翻倍，但换来的是可控的迁移节奏。我做过一次读模型迁移，靠影子流量提前发现了三类数据不一致，全是在测试环境复现不出来的边界情况。

7.3 别把“演进”做成“重写”

最后说一个我见过最多的翻车方式：以“架构升级”为名做整体重写。重写的最大问题是，旧系统里的那些隐性规则——某个字段为什么这么算、某个接口为什么有特殊分支——没人说得清，重写时全部丢失，上线后一地鸡毛。

靠谱的做法是绞杀式替换：新结构先承接一小块流量，稳定后逐步扩大，旧结构随着流量迁走逐步下线。整个过程旧系统一直在跑，随时可回退，用户完全无感。速度慢一点，但没有一次性崩塌的风险。

我个人在实际操作中的体会是，架构这件事最难的不是学会某个模式，而是判断“现在到底该不该动”。我的经验是：当你连续两周都在为同一个结构问题绕路、写补丁、跟同事解释为什么这里不能改，那就是该动手的信号了；如果只是看了篇文章觉得某个模式很酷，那就先放着，等真有痛感了再说。结构是服务于业务的，不是反过来。