聊聊能落地的架构设计方法：别拿大厂PPT忽悠小团队
上周跟一个创业公司的技术负责人喝酒，他拍着桌子吐槽。说花大价钱请了咨询公司做架构设计，画了一堆分层图，上线三个月崩了八次。
钱花了几十万，落得这个结果，换谁都气。
很多人学架构设计，上来就学一堆方法论，背一堆架构模式，出去做项目还是错的一塌糊涂。问题出在哪？根本不是你方法背的少，是你学的方法，都是飘在天上的，不落地。
软件架构设计踩坑梳理白板记录
我现在带人做新项目的架构设计，第一步永远不是开需求评审会，是拉上两三个做过同类型项目的老人，找个会议室点个奶茶，列出来——过去三五年，你们做这个品类项目，踩过的所有印象深刻的坑。
做电商的，就列出来：大促流量顶不住、库存超卖、订单重复、支付回调重复通知...这些都是实打实踩过的，不是脑补出来的。
把这些坑按影响大小排个序，架构设计第一个要满足的，不是未来三年的扩展性，是把这些已经发生过的坑给填上。
架构设计，首先是帮我们避坑，其次才是满足需求，最后才谈什么扩展性。
之前做一个To B的客户管理系统，刚入行的时候我照着标准MVC分层画完图，感觉完美，结果客户上线前提了个要求：所有员工的操作都要留不可篡改的审计日志，任何人不能删改。
这下傻了，所有接口都要加日志逻辑，改了整整两周，差点延期。后来再做同类项目，我第一个就把审计日志的架构埋进去，不管客户提没提，先留好位置，再也没踩过这个坑。
对嘛，吃过的亏，不能白吃。
软件架构可变不变边界划分示意图
之前见过一个跑了快十年的社区项目，从头到尾就是一个单体，人家核心代码不动，所有新功能都做成插件放在单独的目录，加功能改功能从来不碰核心，这么多年下来，除了偶尔加个服务器，从来没出过大架构问题。
这不比那种拆了七八个服务，调用链乱成麻，出了问题查半天的架构强？
不过话说回来，很多人做着做着就把边界做没了。为了省点事，controller直接调dao，上层改下层的东西，改着改着就变成一坨屎，谁都动不了，这本质不是分层的问题，是没守住边界。
再漂亮的分层，乱改边界，最后也是烂摊子。
别为十年后设计，你活不到那时候
这句话是我用几十万的教训换回来的。
刚工作第五年，我接了公司一个新项目，老板说我们要做支撑亿级用户的平台，未来要成为行业第一。我那年轻啊，信了，吭哧吭哧设计了大半年，把能拆的都拆了，能抽象的都抽象了，所有地方都留好了扩展接口，就等着未来用户涨上来不用改架构。
结果呢？项目做了一年多，上线后用户才不到八万，需求改了三波，当初老板画的饼根本没实现，原来的设计全废了，之前写的一大堆抽象层，根本没用上，最后全部推翻重写。
那段时间天天加班到十点，想起这件事就懊恼。
现在行业变得多快啊，你今年做AI生成内容，明年可能就转去做AI硬件了，公司能不能活过三年都不一定，你设计十年后的架构，留给下一任老板用？
什么叫扩展性？不是你提前给所有可能的变化留好接口，那叫过度设计，浪费时间。真正有用的扩展性，是你现在的架构，改起来不费劲就行。
你现在是单体，只要边界划得清，半年后用户涨上来了，要拆微服务，直接拆就行，根本不用现在就拆。你现在拆了，不仅拖慢现在的进度，还多出一堆运维、协调的成本，说不定产品还没跑通，公司现金流就没了，架构再完美有什么用？
去年有个做AI应用的创业团队找我看他们的架构，上来就给我看他们的通用大模型接入层，说已经抽象好了，以后不管接GPT还是文心还是 Claude，直接加配置就行。我问他，现在你们产品用了几个大模型？他说，就用GPT，现在先做好抽象，以后省事儿。
我跟他说，你先把产品做出来，拿到用户，拿到钱，再接第二个第三个模型，到时候再抽象能死吗？你现在花一个多月搭框架，产品拖一个多月上线，竞争对手都跑你前面去了，你留那抽象给谁用？
他回去想了想，把那堆没用的通用层砍了，先写死对接GPT，三个月就上线拿到了种子用户，顺利融到了下一轮。上个月碰到他，他说现在确实要接第二个模型了，正准备抽抽象，那时候心里有底，知道该怎么抽，不像当初瞎蒙。
很多人说，架构设计方法要高大上，要跟大厂对齐，要用最新的技术。
其实哪有那么多玄乎的。
适合你当前团队规模、当前业务阶段的，就是最好的。
上次那个吐槽咨询公司的技术负责人，后来把花几十万做的四层微服务架构，改回了边界清晰的单体，把之前踩的坑一个个填上，现在系统稳定得很，服务器成本直接降了三分之二。
你看，就这么简单。
别从需求倒推，从「坑」倒推
大部分教材教你的路径：先梳理清楚所有需求，再拆分模块，选技术栈，最后画图评审。 对不对？看起来没错啊。 可实操起来呢？需求会变，客户会改，你一开始对着需求做出来的架构，刚好就是最容易踩坑的地方。 说实话，我做了快十五年技术，见过的项目，90%不是死在需求没满足，是死在没人提前想到的坑里。软件架构设计踩坑梳理白板记录
我现在带人做新项目的架构设计，第一步永远不是开需求评审会，是拉上两三个做过同类型项目的老人，找个会议室点个奶茶，列出来——过去三五年，你们做这个品类项目，踩过的所有印象深刻的坑。
做电商的，就列出来：大促流量顶不住、库存超卖、订单重复、支付回调重复通知...这些都是实打实踩过的，不是脑补出来的。
把这些坑按影响大小排个序，架构设计第一个要满足的，不是未来三年的扩展性，是把这些已经发生过的坑给填上。
架构设计，首先是帮我们避坑，其次才是满足需求，最后才谈什么扩展性。
之前做一个To B的客户管理系统，刚入行的时候我照着标准MVC分层画完图，感觉完美，结果客户上线前提了个要求：所有员工的操作都要留不可篡改的审计日志，任何人不能删改。
这下傻了，所有接口都要加日志逻辑，改了整整两周，差点延期。后来再做同类项目，我第一个就把审计日志的架构埋进去，不管客户提没提，先留好位置，再也没踩过这个坑。
对嘛，吃过的亏，不能白吃。
分层不是必须，「职责边界」才是
现在网上搜架构设计，十个教程九个给你画框框：标准三层架构，六边形架构，微服务分层...给你标得清清楚楚，这个框放什么，那个框放什么。 我刚面试的时候也背这个，说不出来几个架构名词，都不好意思说自己是做架构的。 做项目做多了才发现，很多团队纯纯是为了分层而分层。十几个人的团队，不到十万日活，硬生生拆了八个微服务，改一个小小的需求，要改三个仓库，部署要等一下午，出了问题要拉三队人一起查，这不叫架构设计，这叫自找不痛快。 架构设计的核心从来不是分了几层，拆了几个服务。 把变的部分和不变的部分彻底切开，就是好架构。 不管你是单体还是微服务，只要边界清，就是合格的。 比如你做内容平台，用户注册登录这套逻辑，三年五年都不会变，那它就得是独立的，不管你放在同一个项目的独立包，还是单独拆成服务，谁也不能乱改它的逻辑，调用只能走指定接口。 但你首页的推荐算法，营销活动，半个月换一次玩法，那你就把这部分彻底跟核心业务分开，爱怎么折腾怎么折腾，改崩了也不影响用户登录付费。软件架构可变不变边界划分示意图
之前见过一个跑了快十年的社区项目，从头到尾就是一个单体，人家核心代码不动，所有新功能都做成插件放在单独的目录，加功能改功能从来不碰核心，这么多年下来，除了偶尔加个服务器，从来没出过大架构问题。
这不比那种拆了七八个服务，调用链乱成麻，出了问题查半天的架构强？
不过话说回来，很多人做着做着就把边界做没了。为了省点事，controller直接调dao，上层改下层的东西，改着改着就变成一坨屎，谁都动不了，这本质不是分层的问题，是没守住边界。
再漂亮的分层，乱改边界，最后也是烂摊子。
别为十年后设计，你活不到那时候
别为十年后设计，你活不到那时候
这句话是我用几十万的教训换回来的。
刚工作第五年，我接了公司一个新项目，老板说我们要做支撑亿级用户的平台，未来要成为行业第一。我那年轻啊，信了，吭哧吭哧设计了大半年，把能拆的都拆了，能抽象的都抽象了，所有地方都留好了扩展接口，就等着未来用户涨上来不用改架构。
结果呢？项目做了一年多，上线后用户才不到八万，需求改了三波，当初老板画的饼根本没实现，原来的设计全废了，之前写的一大堆抽象层，根本没用上，最后全部推翻重写。
那段时间天天加班到十点，想起这件事就懊恼。
现在行业变得多快啊，你今年做AI生成内容，明年可能就转去做AI硬件了，公司能不能活过三年都不一定，你设计十年后的架构，留给下一任老板用？
什么叫扩展性？不是你提前给所有可能的变化留好接口，那叫过度设计，浪费时间。真正有用的扩展性，是你现在的架构，改起来不费劲就行。
你现在是单体，只要边界划得清，半年后用户涨上来了，要拆微服务，直接拆就行，根本不用现在就拆。你现在拆了，不仅拖慢现在的进度，还多出一堆运维、协调的成本，说不定产品还没跑通，公司现金流就没了，架构再完美有什么用？
去年有个做AI应用的创业团队找我看他们的架构，上来就给我看他们的通用大模型接入层，说已经抽象好了，以后不管接GPT还是文心还是 Claude，直接加配置就行。我问他，现在你们产品用了几个大模型？他说，就用GPT，现在先做好抽象，以后省事儿。
我跟他说，你先把产品做出来，拿到用户，拿到钱，再接第二个第三个模型，到时候再抽象能死吗？你现在花一个多月搭框架，产品拖一个多月上线，竞争对手都跑你前面去了，你留那抽象给谁用？
他回去想了想，把那堆没用的通用层砍了，先写死对接GPT，三个月就上线拿到了种子用户，顺利融到了下一轮。上个月碰到他，他说现在确实要接第二个模型了，正准备抽抽象，那时候心里有底，知道该怎么抽，不像当初瞎蒙。
很多人说，架构设计方法要高大上，要跟大厂对齐，要用最新的技术。
其实哪有那么多玄乎的。
适合你当前团队规模、当前业务阶段的，就是最好的。
上次那个吐槽咨询公司的技术负责人，后来把花几十万做的四层微服务架构，改回了边界清晰的单体，把之前踩的坑一个个填上，现在系统稳定得很，服务器成本直接降了三分之二。
你看，就这么简单。