说实话，我以前是个坚定的分层架构党。 我刚入行那会儿，在一个做银行核心系统的外包项目里，代码结构永远是controller/service/mapper三层，谁要是敢在controller里写业务逻辑，code review绝对通不过。 当时这套规矩看起来特别专业，直到有次我们做一个“用户余额显示”的需求，由于余额要增加精度，从数据库字段到前端接口需要改实体、DTO、service、controller四层，结果我忘了改DTO，数据在接口层被四舍五入，线上用户看到少了8分钱，最后被运维连夜拉起来回滚。 那一刻我就开始怀疑：分层是在帮我们组织代码，还是在给我们制造轮子？
后来我接触了垂直切片（Vertical Slice）架构，才明白问题出在“按技术分层”这件事本身。 传统三层架构，一个业务功能会横穿所有技术层，改一个需求要同时修改多个文件，而且这些文件往往散布在不同目录；垂直切片则把同一个业务功能的所有代码放在一个包或者模块里，比如订单模块就是一个OrderController、OrderService、OrderRepository的组合，甚至干脆用一个OrderHandler搞定全部流程。 举个例子，如果要做“下单时扣库存+生成支付记录”，三层架构下你要改OrderController、OrderService、InventoryService、PaymentService四个类，而垂直切片只需要改一个OrderPlacement类，里面编排调用其他模块的基础服务。 区别不是文件数量这么简单，而是变更的影响范围被压缩了，你不再需要同时打开四个目录去理解一个完整的业务流程。
但垂直切片也不是没有缺点，它最大的坑是重复代码。 比如多个切片都需要查用户信息，如果每个切片都自己写一句“select user by id”，那不出三个切片就会让你想骂人。 后来我们项目做了个折中：将真正底层的、跨切片复用的操作抽到公共模块，业务内的高内聚留在切片里。 实际数据是，我们花了两周重构了一个订单服务，从三层切到垂直切片，结果修改平均改动的文件数从5.2降到了1.8，单元测试数量从220个减到130个，构建时间从4分20秒缩短到2分10秒，但代码行数总体只少了12%。 这个数字不一定适合所有团队，但至少说明垂直切片在减少认知负担上是有效的，尤其是在业务规则复杂的地方。
不过我想说的关键观点是：比起选择哪种架构，更重要的是学会“按变更频率来组织代码”。 有些模块很稳定，比如用户状态字典，你一年都不会动它，放在传统三层里完全没问题；有些模块频繁变更，比如营销活动的规则，如果也被切成三层，那么每次活动改一点点，你都得从头改到尾。 所以我现在更愿意采用一种“混合模式”：把频繁变更的菜单做成垂直切片，把稳定的基础查询保持传统分层。 这样做确实打破了架构的“纯粹性”，会招来一些洁癖的嘲讽，但项目的目标是活下去，不是上台领奖。 另外还要注意，垂直切片不是简单地把文件扔到同一个包，你得定义清晰的输入输出模型，避免切片之间互相渗透，否则最后会变成一个大泥球。
最后说点大实话：架构没有银弹，也没有完美的最佳实践。 我见过一个6人的创业团队，坚持用整洁架构，硬是写了两千行的泛型基类来满足那套理论，结果所有人都离职了；也见过一个老牌ERP，所有逻辑都在controller里写了十几万行，可它能稳定运行十年。 我的建议是，下次当你为一个新模块纠结该用三层还是垂直切片时，先别急着套模板，画一张变更频率表，哪个接口每天被改就优先把它垂直切。 另外，如果你真的想尝试垂直切片，可以从一个很小的需求开始：新建一个功能包，把请求处理、业务规则、数据访问都放在里面，然后看看有没有让你不舒服的地方。 不管用什么架构，最终都要记住一条：代码是写给人看的，不是给架构图看的。
