软件架构设计

架构设计是高层设计，是设计决策之上的决策。它为决策引入的额外的约束，这种约束不产生立即可见的效果。

用一个例子来辅助我们的表述。比如你买了一间新房子，有5个房间，你的床放哪里？书柜放哪里？马桶放哪里？微波炉放哪里？(允许先假定哪里都有下水管道之类的设施)

如果按眼前的决策，刚进来的时候，哪里都能放。而且，这个判断最快了。但等你在床旁边安装了一个马桶。或者每个房间都安排了书柜，导致想放张大一点的床都放不下的时候，那就不由得感慨：早知道就……了。

那么提前决定买多大的房子，房子有多少房间，不同的房间是什么功能，就是架构设计工作要做的工作了。

01

架构工作呈现为约束。你搬一个微波炉进来，看见有块空地，你觉得就应该放下来了，这毫无约束。但架构工作会给你增加额外的约束——“你不能放这里，你必须放到那个贴着‘厨房’标签的的房间里”。所以架构工作总是讨人嫌，而且带来的好处人们总是说“这本来就是这样的”，因为这个微波炉本来就是他搬进去的呀。

02

架构工作在初期都表现为不是非做不可的样子。就如同这个例子中，你买了300平的大房子，把你出租屋的那些破烂搬进来，全扔杂物房就可以了，不需要“设计”。但如果你不“设计”，后面你的房子可能就一塌糊涂，没法用。

架构体现价值总出现在设计的后期，特别是所有的约束都被实施上来的时候。那时你会要求睡房里不要有潮湿的东西，书架旁边不要有带火的东西，电源线不能拉太远，洗衣机旁边必须可以排水之类的要求了，这些要求会互相冲突。

03

有效的架构工作很难呈现出直接被外行看到的模式或表象。比如你找个神棍来给你的房子看风水，他用罗盘给你看半天，要求你每个房间里放个马桶，再养条金鱼进去，不仅给你增加约束，还表现的很专业的样子，你也无法事后说他不对：“虽然你每天都要闻着臭味睡觉，但这给你增加财运啊，你现在没有住医院，都是我给你摆的这个阵给你压着的”。虚假的架构师还喜欢用什么是自己做的来声称自己架构做得好，这也只是骗外行，因为架构好不好是看使用效果好不好(一定程度上表现为具体设计，特别是后期的具体设计和使用者自己的‘使用设计’是否容易做)，而不是架构设计本身难不难，好不好看，多不多，好不好。

04

架构无法被简单评价，因为每个架构的实施，都是独一无二的。架构也不是在选择不出任何问题的路线，架构只是在选择出问题比较少的路线。不出问题对你来说可能就是应该的，出了问题你都会说“早知道我就……”。你以为“你早知道就……”，其实你早那样，别的地方就该出毛病了。其实，大部分时候，你的房子住得还可以，没有出什么大问题，比起情况差不多的人来说还有些明显的优势，你的架构就可以了。只是大部分情况下，你也不会说架构设计师的什么好话。现在新冠病毒肆虐，你说早该隔离了，但假定早隔离保证这个病毒没有发作，你又该说当初的实施者吃饱了撑的了。

05

架构无法被细致化，细致化的架构无法响应变化，比如你提前决定每个家具摆放的位置，如果某个家具不能到货，你就处理不了，你考虑所有可能的组合呢，这个工作量你无法承担。所以，架构不是一次性的工作，而是一个长期的过程，是一个设计，响应，再设计，再响应……的一个连续循环的过程。架构设计不能着眼于眼前，也不能离开现实。很类似《道德经》的一个表述：豫兮若冬涉川，犹兮若畏四邻，俨兮其若客，涣兮若冰之将释，孰兮其若朴，旷兮其若谷，浑兮其若浊。架构远了不行，近了也不行。

06

架构的工作很多都表现为不能一次成功，比如你为了装修，在外墙会建脚手架，事后你会拆掉它，你不能说这是“浪费时间”，架构功能常常通过这种脚手架工作体现出来的。它不呈现你想象的纯粹“指挥别人干活”的样子。

07

架构只能靠建模进行逻辑验证，真正的验证只有实施的时候才知道。你单考虑水、电、通讯、家具的时候，可能逻辑是通的。但把它们放在一起，就不一定了，每个独立的建模都有边际效应，这种边际效应会互相影响。

最后，架构几乎无法回头，如果你一开始就没有做架构设计，房子里面的线拉得到处都是，每个房间都安排了一些排水设施之类的。或者你干脆买错了房子，这个位置根本没有公交系统，你还没车，你除了把房子卖掉重新找一间，你没有任何办法。

所以，架构这种东西，就像鸡汤，你说它没用，没有这种设计的时候，你就是老出问题，你觉得你“做了架构设计”，这只是个名义，它也不保证你不出问题。

架构设计的方法一般来自四个输入：

01

架构师在这个问题上的经验。比如他以前干过很多次这个事情，每个家庭都是有厨房、卧室、卫生间的，分开有好处，他在没有任何约束的时候，都会制造这个约束，这也确实会带来好处。因此，也不存在跨行业的架构设计，没有实际经验，哲学再好也不能成为架构师(当然，充神棍说不定可以)

02

高层逻辑建模。设计师会在一个很高的层次上构造一些逻辑链，保证这个逻辑链是自恰的，先用这些逻辑链建立约束。比如他会先问：你住在这里是为了什么？为了孩子上学的方便？那么上班怎么办？……这个逻辑通了，他才会讨论是否买车，房子如何设计车库书房这类的问题。

03

竞争对比。“别人怎么做的”，特别是“成功者是怎么做的”

04

反复的投资收益对比。设计师可能想的是一件事怎么做，而架构师想的是这件事的成本是多少，是否有钱做，能否找别人做。架构师还要观察每波投资的时机，让每波投资进入系统的时候，都能成为架构目标的助力(“动善时”)。所以成功的架构过程几乎不可能被复制，因为架构过程是和外部输入的时机紧密结合在一起的。房子要填一个小洞的时候，正好邻居有一些沙子要扔，这个时机，你没有准备，就没有办法利用上。软件更加是这样，使用方的投资的时候，你不成熟不会用你，你成熟了你不需要它，你要做好一这个软件，就要排布一个用户机会计划，靠这些用户催熟你的软件，这需要一个计较和设计。没有应用可以仅在实验室就成熟的。

另外

架构设计还会引入一些其他策略！

比如“不为天下先”，每个架构设计引入的约束，都会被要求找到一个“收益”，这样虽然不能解释为什么，但减少了约束，就为未来响应变化增加了机会)。比如有人建议，“所有房间都要装排风机”，加排风机需要成本，但这个成本看不到收益，那么我们宁愿逻辑复杂一点，某些房间装排风机，某些房间不装，某些房间开窗户……我们也不能提前增加这个约束，这样我们才能在后面根据需要决定装排风机，还是保持密封用来存储东西之类的。“不为天下先”，是为未来增加需求留下余地。好的架构师极其反感没有收益的设计约束，而装样子的架构师喜欢引入无效的约束来证明“我也干了活”。

等等······

说到底，架构是在自由阶段增加约束，把未来你有可能遇到的约束提前统一在一起，以保证你设计的后期减少约束。架构师分析逻辑链总是不考虑“这是对的”，而是考虑“少了什么”。比如有人说，我在房间里放一张床，两个衣柜，一盏灯，是不是就可以了？架构师不考虑单独的床，衣柜是不是可以，架构师考虑的是总成本是多少，房间有多大，用来干什么，然后才决定一张床两个衣柜是不是对的。所以它总是从逻辑的全集来考虑问题。也正因为这样，架构师比一般具体设计的设计师更关注边界和边界上的需求和约束，因为一个简单的需求判断的不同，就会带来一个软件架构翻天覆地的变化。

版权声明：凡非原创内容，皆秉分享宗旨，图文整理自网络公开信息，版权属原持有人，亦非本公众号观点，如有侵权，请联系我们删除。