写给一线工程师的架构设计方法：跳出八股文陷阱
上周跟一个工作五年的后端开发吃饭，他掏出电脑给我看刚做的架构方案。我翻了三页，差点噎着。
全是漂亮的分层图、标准的大厂模板，问他解决了什么具体问题，他支支吾吾说不清楚。
这不是个例。太多工程师学架构，从一开始就走错了路。
从业务痛点推导架构设计流程图
你做设计的第一步，永远是把你当下要解决的痛点列出来。哪些是现在必须解决的，哪些是三年后才可能遇到的，别把未来的问题提前到现在解决。
很多人把“留好扩展性”挂在嘴边，为了不确定的未来，把当前的架构搞的无比复杂，结果扩展性留了，代码烂了，业务变了，当初预留的扩展性根本用不上，反而拖死了当前的开发效率。
对吧？
架构设计变化点隔离示意图
第三个，坏味道反向推导法。你写完方案，别着急吹，反过来捋一遍：哪里最容易出问题？出问题之后影响范围有多大？峰值的时候会不会打挂核心交易？数据量涨十倍之后，哪个点先顶不住？把这些可能出问题的地方提前做预案，比追求百分百完美的设计有用多了。
第四个，降维试错法。拿不准怎么拆分的时候，先写一个简单的单体版本跑两三个月，哪里堵了再拆，别上来就拆得稀碎。很多人怕做错，一开始就追求一步到位，结果业务方向一变，之前拆的全错了，白忙活好几个月。
不过话说回来，这四个小动作没什么高大上的，都是踩坑踩出来的实战经验，比那些玄乎的理论管用得多。
别被趋势绑架，适合的才是对的
这两年你肯定也感受到了，行业里追趋势追得离谱。云原生火了，所有项目必须上云原生；Serverless火了，不管什么项目都要改造成Serverless；DDD火了，哪怕一个小工具也要划限界上下文搞战术设计。
去年有个朋友找我吐槽，说他们公司新上任的CTO要求，所有项目架构评审，不用微服务云原生的直接打回，不然不给过。结果一个内部用的员工考勤查询系统，上了微服务之后，光配置网关、注册中心就花了一周，成本涨了三倍，出问题查日志跨好几个服务，比原来的单体慢了不止一点。
图啥呢？
架构设计方法的核心，从来不是你用了多么先进的技术，是你有没有匹配当前的团队规模、业务阶段和实际需求。我之前见过一个做户外品牌的老牌电商，核心交易系统还是十年前的单体架构，人家维护得好好的，每年几十亿流水，稳得一批，谁说人家架构落后了？
微服务当然好，那是给几千人研发团队、亿级流量准备的。小团队十来个人，玩微服务，就是自找苦吃。服务拆分带来的协作成本、部署成本，远远超过你能拿到的收益。
说句不好听的，很多人追趋势，就是为了写简历好看，跟解决问题半毛钱关系没有。前阵子我刷到一个应届生写的架构方案，十万DAU都不到，把能堆的概念都堆上去了，我数了数，光设计模式就用了七种，改个接口得动七个地方，这不是设计，这是给自己挖坑。
真正好的架构，做完之后大家只会觉得，本来就该这么设计，不突兀，不复杂，安安稳稳解决问题。不是拿出去给别人吹，你看我用了多少新技术新方法。
做架构跟开饭馆差不多。你开个路边馄饨铺，就没必要搞米其林摆盘，客人要的就是十块钱一碗热乎，十分钟能上桌，你给人上一份几百块的分子料理，客人吃不惯，你也赚不到钱。
就这么简单。
别从模式开始，从痛点开始
现在打开任何一个架构教程，一上来就是MVC、微服务、CQRS、DDD，各种模式堆给你，轮到你自己接需求做设计，还是抓瞎。 说实话，我刚工作那几年也犯这个错。做个不到十个人用的内部管理系统，上来就拆八个服务，搞得运维同事天天骂我，出问题查日志跨三个团队，最后上线不到半年又全部合并回去，说多了都是泪。 架构设计的本质，从来不是套模板炫技，是解决具体问题。 去年我帮一个创业公司做交易系统选型，创始人上来拍板就要做微服务，说大厂都这么干，不做就是落后。我拉着产品和研发理了三天需求，核心用户才不到一万，QPS峰值不到两百，整个研发团队才四个人。 最后给的方案就是单体加模块拆分，部署就一台高配置云服务器，一年下来成本省了十几万，跑了快两年，稳得一批，没出过什么大问题。从业务痛点推导架构设计流程图
你做设计的第一步，永远是把你当下要解决的痛点列出来。哪些是现在必须解决的，哪些是三年后才可能遇到的，别把未来的问题提前到现在解决。
很多人把“留好扩展性”挂在嘴边，为了不确定的未来，把当前的架构搞的无比复杂，结果扩展性留了，代码烂了，业务变了，当初预留的扩展性根本用不上，反而拖死了当前的开发效率。
对吧？
四个亲测有用的小动作，比背模式管用
我跟十几位工作十年以上的资深架构师聊过，没人会拿着模式对照表套方案，大家都有自己顺手的小习惯，我整理了四个，踩了无数坑攒出来的，亲测好用。 第一个，角色/责任拆分法。别上来就分模块分服务，先把系统所有要干的活一条一条列出来，再给每个活找对应的业务角色，同一个角色的活放一块，不同角色的责任切开。做电商交易，订单管状态流转，支付管收钱对账，库存管出货扣减，本来就是不同角色的核心责任，切开当然没问题，要是硬把优惠计算塞到订单服务里，时间长了需求一变，肯定乱成一锅粥。 第二个，变化点隔离法。哪个地方会频繁变动，就把它从核心逻辑里摘出去，单独隔离，别让它污染核心代码。我们之前做ToB项目，每个客户的对账规则、出账周期都不一样，一开始把对账逻辑写死在核心交易里，改一次需求发一次版，客户骂我们响应慢，我们改得头大。后来把对账逻辑拆成独立的配置化规则引擎，改需求不用动核心代码，运营自己就能配，省了好多事。架构设计变化点隔离示意图
第三个，坏味道反向推导法。你写完方案，别着急吹，反过来捋一遍：哪里最容易出问题？出问题之后影响范围有多大？峰值的时候会不会打挂核心交易？数据量涨十倍之后，哪个点先顶不住？把这些可能出问题的地方提前做预案，比追求百分百完美的设计有用多了。
第四个，降维试错法。拿不准怎么拆分的时候，先写一个简单的单体版本跑两三个月，哪里堵了再拆，别上来就拆得稀碎。很多人怕做错，一开始就追求一步到位，结果业务方向一变，之前拆的全错了，白忙活好几个月。
不过话说回来，这四个小动作没什么高大上的，都是踩坑踩出来的实战经验，比那些玄乎的理论管用得多。
别被趋势绑架，适合的才是对的
别被趋势绑架，适合的才是对的
这两年你肯定也感受到了，行业里追趋势追得离谱。云原生火了，所有项目必须上云原生；Serverless火了，不管什么项目都要改造成Serverless；DDD火了，哪怕一个小工具也要划限界上下文搞战术设计。
去年有个朋友找我吐槽，说他们公司新上任的CTO要求，所有项目架构评审，不用微服务云原生的直接打回，不然不给过。结果一个内部用的员工考勤查询系统，上了微服务之后，光配置网关、注册中心就花了一周，成本涨了三倍，出问题查日志跨好几个服务，比原来的单体慢了不止一点。
图啥呢？
架构设计方法的核心，从来不是你用了多么先进的技术，是你有没有匹配当前的团队规模、业务阶段和实际需求。我之前见过一个做户外品牌的老牌电商，核心交易系统还是十年前的单体架构，人家维护得好好的，每年几十亿流水，稳得一批，谁说人家架构落后了？
微服务当然好，那是给几千人研发团队、亿级流量准备的。小团队十来个人，玩微服务，就是自找苦吃。服务拆分带来的协作成本、部署成本，远远超过你能拿到的收益。
说句不好听的，很多人追趋势，就是为了写简历好看，跟解决问题半毛钱关系没有。前阵子我刷到一个应届生写的架构方案，十万DAU都不到，把能堆的概念都堆上去了，我数了数，光设计模式就用了七种，改个接口得动七个地方，这不是设计，这是给自己挖坑。
真正好的架构，做完之后大家只会觉得，本来就该这么设计，不突兀，不复杂，安安稳稳解决问题。不是拿出去给别人吹，你看我用了多少新技术新方法。
做架构跟开饭馆差不多。你开个路边馄饨铺，就没必要搞米其林摆盘，客人要的就是十块钱一碗热乎，十分钟能上桌，你给人上一份几百块的分子料理，客人吃不惯，你也赚不到钱。
就这么简单。