怎么样的架构才是好架构？

正文

请到「今天看啥」查看全文

某块代码维护的次数多了，特别是中间由多个人接手过后，代码风格各异，难以理解。

相似的代码在好几个地方出现，特别是一些非业务性的代码，比如日志处理等。再甚是在大型的分布式系统中，不同子程序使用了不同的同类型中间件，同样导致维护成本大增。

在 2 个相依赖项目边界处的设计产生了分歧，并且站在各自的角度看都有道理。

任何事物都是有两面性的，并不是说上面的这些问题，我们通过架构就要往另外一个极端去走 。比如在大型的分布式系统中，不同子程序的确有必要在某些时刻选择同类型的其它中间件。如 Kafka 和 RabbitMQ 虽都是 MQ，但在特定的场景下能发挥的价值是无法相互替代的。

所以我们做架构有一点也是比较重要的，就是去 Balance ，选择一个投入产出比最优的方案。关于这点第四段中会多说几句。

除此之外，架构的主要目的是为了让大家往同一个方向，在同一个标准之上去发散扩张。 一是把控硬性的下限标准，提高整体的最短版，二是提高上限水平位，也就是天花板位置，提供更大的发展空间 。好比造一幢大楼，把框架结构设计好搭好，让大家形成一个共识，什么是承重墙不能破坏，什么是创变空间可以自定义。在这样的基础下各自发展。这个看上去是个限制，但却是做架构最重要的任务，所谓 再多的文档，再多的最佳实践都比不上一条约束 。降低复杂度、降低理解难度，是实实在在的收益。最怕的就是凭空假设带来的过度浪费。

更甚之，我们做架构追求的理想国度是一个大家拥有一致共识的世界，架构是大家都像吃饭喝水这样习以为常的习惯。去理解或者接手其它人负责的项目的时候就好像是自己写的一样。这个时候就消灭架构了，就好比现在没有人会教你如何吃饭一样。

做架构的最佳实践

上面提到更多的是做架构的目的，那么要做好架构，主要就是要做好抽象，做抽象的方式是类比，做类比的方式可以使用用例图。所以建议大家多画图，通过画图来将大脑中抽象的结果直观的体现在前面，再来进一步分析合理性。主要推荐 2 种图的类别，一种就是前面提到的用例图。如下图：

请到「今天看啥」查看全文