如何评价一个架构的好坏？
最近设计了几个架构，每次设计完成后，心里都会想，这个架构到底是好是坏？我会不会把组内的人给坑了？有没有一个标准来衡量，这个架构目前就是好的？简单的讲，我们设计了一个架构，我们怎么敢说这个架构是好的？
一个好的架构
总结下来，一个好的架构可以从下面几个方面去评估：
包括：形式，效果和实施三个维度。
形式
评价一个架构形式，第一个原则就是：高内聚，低耦合。这里面的关键在于：内聚的边界在哪儿？耦合的边界在哪儿？，什么样的内聚才算高内聚？什么样的耦合才是低耦合？有点难以把握，所以，我加了一点：职责明确，关系清晰，跟高内聚，低耦合配合起来一起看一个架构形式。
职责明确
分析一个架构的时候，首先看每个模块的职责，那怎么才算一个“职责”呢？
职责：业务上不可分割的原子操作
在判断是不是高内聚，是不是职责明确的时候，第一步就是先分析职责。我把职责定义为上面的形式，在业务上不可分割的原子操作。例如，共享单车的开始订单操作是一个职责，包括了：创建订单，开始计费，开锁等操作，他们在业务上是一个整体，其中只拿出一项而言，对业务都没有意义。另外，这个地方的业务，不一定是面向用户的业务，像一些中间件系统，这个时候的业务就是对系统功能而言。
接下来，就是把模块的这些职责列出来，看看是不是明确的，进而看看是不是内聚的。其实，这几个词还是没法客观的给一个标准，就像计算1+1一样，如果等于2就是对的。这里面很大程度还是依赖于一个主管的判断。这个主管的判断我觉得可以借助于费曼学习法，就是：把这个系统的职责，讲给一个不熟悉这个系统的人听，看看能不能用最简洁的语言描述清楚。另外，还可以从另外一个视角去看，内聚的背后驱动力其实是领域化和分工的不同，所以，如果一个人要掌握这个系统，需要具备不同领域的知识，那么就一定是内聚了太多的职责。
关系清晰
如果职责明确，高内聚不好客观的评价，但是，关系清晰和低耦合确实有办法来衡量：那就是画关系依赖图。,所以，一个好的架构师，一定能够对整个系统的职责有明确的认知，然后画出一张清晰的关系依赖图，然后从这张图里面，发现问题，找出优化的方向。
看一个最简单的例子，在关系1中，是比较好也是比较理想的情况：模块A单向依赖模块B，如果一个系统所以的模块都是单向依赖，并且不存在循环依赖的话，整个系统就是分层的树,层次清晰。
然后，往往存在大量如关系2中的依赖关系，造成这种关系基本上都是职责不明确所致：要么把依赖的职责抽离出来放到模块C或者模块D上，要么单独抽取一个底层模块，供上层C和D使用。
总的来说，从形式上，本质上关注职责明确和职责内聚，但是，往往有的时候我们很难给一个客观的标准去衡量，所以，更多的时候，我们要梳理清楚依赖关系，把关系理顺，发现模块之间的问题，降低耦合，进行抽取或者内聚，整体上实现分层的树状结构。
效果
一个架构，不管如何设计，都可以当作黑盒，从效果上去评估：
首要的是，能够解决问题
这里面隐含了一个前提，就是识别问题。其实我在很长的一段时间内，以为识别问题是架构师的难点，但根据最近的实践发现，其实问题还是比较容易识别的，因为现在基本上不是从0到1，或者是你一个人在工作，基本上一个团队已经折腾了一段时间，这个时候，痛点，问题大家都知道。只是缺少解决的方案。甚至有的时候解决的方案大家也都知道的大概，只是缺少实施的方案。
其次，能够提效降本。
解决问题只是第一步，接下来就是体现一个好的架构师的能力：提效降本，提高解决问题的效率，降低解决问题的成本。要实现提效降本，难点不在于如何衡量：毕竟这一点还是很容易衡量的，就看投入的资源有多少就好了；难点在于设计出一套提效降本的方案，本文重点不是讲设计，所以大概列一些点：
模型设计和优化
技术引进
技术创新：很难。
其实，架构从直接效果上看是增加了负责度，就好比盖楼，盖一座大厦肯定比盖一间草屋复杂度高，但是，前者却能住更多的人。所以，好的架构一定是平衡了复杂度和收益，最大化提高效率降低成本。
实施
一个架构，如果不能落地就不算架构，所以在评价的时候，还需要评价实施方案，这一块的标准也好制定，主要从两个方面：
时间/人力成本：就看要投入多久，多少人来实现
维护成本：好不容拉一票人开放完成，结构后面很难维护，也算一个失败的架构。
总结
这么看，整体上除了内聚和职责明确，这一块不好衡量之外，其他的都是可以衡量的：
依赖关系清晰：画一个系统依赖关系图，越细越好，另外，既然是关系，就要有强弱依赖，也要理清楚
效果也可以衡量：给别人清楚你设计这套架构能带来的收益，要讲清楚不要模模糊糊
实施成本也尽可能衡量：有的时候实施成本不能一下评估准确，而是在开发的过程中发现一些问题，这个时候要主动拉更多的人讨论，看看有没有潜在的坑，尤其是对遗留系统的重构。
source: https://lishoubo.github.io/2019/05/03/如何评价一个架构的好坏？/
喜欢，在看