从《置身事内》读到软件架构

前段时间读了吴晓波的《激荡三十年》，讲述的是从改革开放1978年中国最近40年企业的演进史事。后来网友又推荐了这本《置身事内》，读完之后，大有体会，深感国家与地方之间的博弈。有这样的体会，大概是因为这两年跟着领导做了点关于企业级架构方面的事吧，能感受到部门与部门间的利益矛盾，部门在公司愿景下的让步等等逻辑。

下面主要是谈谈自己在架构方面的一点小理解，主要是从下面两个方面阐述：

软件架构中的最佳实践问题

新中国成立之初的国家制度，基本就是照着前苏联的搞法，照搬过来，到了国内实施，起初效果还行，一旦有了点起色，就渐渐不那么奏效了，各种问题，比如承包制。随着邓公一系列的改革开放策略，“摸着石头过河”，“不管黑猫白猫，捉住老鼠就是好猫”，走中国特色社会主义道路，经济发展一路高歌。

最佳实践，对于程序员其实一点也不陌生，日常各种文章，各种书籍，都能看到类似 “XXX最佳实践” 。我们也一直走在寻找各种最佳实践的路上，比如Git的最佳实践，微服务的最佳实践，DDD的最佳实践等等。大家一直再说最佳实践，技术分享，圈子氛围挺好的，但作为受众，不顾思考，不加以装饰的，直接运用到自己的团队或公司，似乎显得就不那么严谨了。

在我工作的第5个年头（2018年）里，我接触了微服务，k8s，中台等，相对比较热门的技术思想，以至于我天天学，夜夜学，恨不得把它们全部实践在自己的项目里，那一年，我的“梦想” 得以现实，这些个东西都落地了，然后我却迷茫了，因为真的很痛苦，太累了，以至于有些东西根本搞不定。原来大厂们搞得热火朝天的东西，别家的公司的最佳实践，到了我们这边，只是做不完的技术债。

好的架构，到底是什么样的？第二年我离职了，决定换个山头看看。

后来，我明白，那些声称的最佳实践，真的有很多是描述并不严谨的，人家只是把最光鲜的一面给了你，而忽略给你提到他们的业务场景（背景）。所以，最佳实践，应该是在特定场景下的最佳实践，不可能一个方案解决所有问题，矛盾总是会存在的。最佳实践，是演进出来的，不可能一蹴而就。我们很难预见多年以后会发生什么。作为合格的架构师，需要了解一个方案适用的场景，更要了解该方案不适用的场景，就像雷总说的 “ 决定不做什么跟决定做什么一样重要”。

或许架构最佳实践可以这样做

• 梳理并理解当前业务场景；
• 抽象业务概念；
• 挑选最佳实践的选型，了解选型的适用和不适用的场景；
• 结合抽象模型，定义选型；

书里面作者介绍了一些制度政策，就和这最佳实践问题一样，很多西方的东西，到了中国就不灵了，还是需要结合自身的现状，做出合理的决策。

软件架构中的边界问题

边界，一个很好理解的词，但在很多事情里它总是相对模糊，比如公司的业务，它的边界在哪，是由公司的使命和愿景决定，然而这两者本身就很大而空（个人理解）。

但是如果有客观评价标准，那么它的边界可能就很简单了，比如比较明显的是国家的领土边界，全世界都认可的，经纬线定位。所以遇到这样的事，按照标准来就好了。

但世间事往往都并非如此，比如架构的边界，在哪，往往就很模糊，难定。

架构里的边界，我们常常用Scope，职责，或者目标，来说明系统的边界在哪，具体点就是一个系统做什么和一个系统不做什么。明确清晰定义后，以便于降低系统复杂度，以便于防止后期跨团队的扯皮等等问题。

边界的定义很难，我的小tips

• 调研，调研，调研，尽可能去与一线人员沟通最根本的业务场景，而不是简单的转述；
• 梳理总结你的几条核心逻辑，少就是多，不要为自己的系统揽太多的职责；
• 找利益相关人达成一致，重要；
• 以发展的眼光看待边界，随着业务的发展可能会需要根据现实不断调整；
• 最后，可以打破边界约束的是规模经济，虽然不是你的Scope，但做在你这收益最高；

抓主要的，其他的不确定的，就让子弹飞一会，当清晰了再做，也不迟。

关于边界问题，作者在书中介绍了，省与省的交界处，因为有利益相关，早期这些地方都是偏“三不管”地带，地方财政很少会管此处，后来国家财政巧妙地介入，才慢慢化解了此问题。

好了，赘述一番，这本书还是非常推荐程序员朋友读读。