避开花架子：真正落地的架构设计方法

我上周跟一个刚升架构师的小伙子吃饭，他拍着大腿吐槽，说跟着网上学了一堆领域驱动、四色原型，真到做项目的时候，对着一堆需求还是不知道从哪下刀。

很多人学架构设计，上来就是画思维导图拆模块，满屏UML类图，最后出来的方案，根本落不了地。

别从需求开始拆，先找你手里的约束

什么是架构设计的第一步？九成的教程都会告诉你，先拆解需求梳理业务流。错了。第一步永远是找约束。

什么是约束？就是那些你不能碰、改不了的条件。你公司全团队只会写Java，你非要整个Go写核心服务，美其名曰性能更好，那不是架构设计，那是给自己挖坑。

小创业公司，预算只够买两台云服务器，你非要设计多活多可用区，光买服务器的钱就把预算烧完了，那不是瞎扯淡吗？

我见过最离谱的方案，是前年某创业公司做社区团购，刚拿了百万种子轮，就照着拼多多的架构抄，光中间件就搭了七八套，上线前运维跑了三个，最后项目撑了不到半年就黄了。创始人说，钱没花在产品上，全给架构买单了。

真正能用的架构设计，永远是先框定所有不能动的约束，再在框里跳舞。脱离约束谈设计，全都是空中楼阁。

能用简单的，绝对别玩复杂的

说实话，现在行业里歪风邪气太重。架构师比谁用的中间件新，比谁的系统分层多，好像少分一层就是水平不够，不用上最新的技术就是落伍。

前阵子帮朋友看一个toB的项目，总共日活不到一千，硬是做了网关、服务发现、配置中心，拆了十几个微服务，每次上线都要出点幺蛾子，服务器成本翻了三倍，开发效率掉了一半，图啥呢？

很多人抬杠，说我这叫提前架构，预留扩展空间。哦哟，你都不知道一年后产品会改成什么样，预留个屁的扩展。预留的空间，最后九成九都会变成技术债，等你真需要扩展的时候，预留的设计早就不符合新需求了，还要推倒重来。

好的架构设计，是刚好满足当前需求的最简单设计。等需求真的变了，再拆再扩都来得及，你又不是造火箭，一次性成型不能改？

去年我们帮客户做一个企业内部的数据分析工具，一开始只有三个付费客户，我们就用单体应用，数据库连读写分离都没做，跑了大半年，客户涨到三十多个，性能不够了，我们花了两周拆了两个核心模块出来，一点问题没有，比一开始就瞎拆分，省了至少三个月的工期。

别迷信方法论，适合自己的才是对的

现在网上动不动就这个架构设计方法那个万能框架，DDD火了就全都是DDD，云原生火了就全都是云原生架构，好像不学你就是落伍十年。

不过话说回来，这些方法论都是人家大厂总结出来，适合人家自己场景的。你一个十几个人的小团队，做个最多活两年的项目，学人家大厂做领域建模，搞事件风暴，开一周会画满一墙便利贴，会开完需求都变了，图啥？

我不是说DDD不好，DDD梳理复杂业务边界确实牛，但是你一个做内部OA工具的小项目，犯得着吗？你上来就硬套，那就是杀鸡用牛刀，累死自己还讨不到好。

还有人把“高内聚低耦合”挂在嘴边，这话没错，但是耦合度降到多少算够？为了所谓的零耦合，搞出几十层适配器，最后改个小需求要改五个地方，这不是本末倒置吗？

我认识一个很厉害的老架构师，他做项目从来不会上来就套方法，他会先问自己三个问题：这个项目最多撑多久？团队有多少人能稳定写代码？出问题最坏的结果是什么？问完这三个问题，再选方法，简单项目用快速原型，复杂项目拆清楚边界再动手，大团队分模块，小团队怎么快怎么来。

很多人说，这也太不专业了吧？专业不是对着方法论生搬硬套啊，专业是解决问题啊！架构设计的本质，不就是帮业务落地，帮团队提效吗？你方法用对了，问题没解决，那叫什么专业？

那些动不动就把架构设计吹得玄乎其玄，几十页PPT全是新名词的，说白了很多都是割钱的幌子，方案写得天花乱坠，真正落地能用的不到十分之一，你说气人不气人。

其实做个三五次项目你就会发现，架构设计方法哪有那么神秘，说白了就是经验堆出来的，踩过几次坑，就知道什么不能做：知道约束要先找，知道简单比复杂好，知道别瞎套别人的方法论。

我见过刚工作三年就能做得很好的年轻架构师，也见过工作十年了还只会套模板的老人，差就差在有没有动脑子想——你的项目到底需要什么？

下次开架构设计会之前，不妨放下手里的畅销书，喝口茶，想想你手里有多少钱，有多少人，要做成什么样，再动手，比你上来就画满一黑板模块图靠谱多了。