如何评价一个架构的好坏？

最近，我设计了几个架构。每次设计完成后，我都会想，这个架构是好是坏？我会坑小组里的人吗？目前有没有标准来衡量这个架构是否好？简言之，我们设计了一个架构。我们怎么敢说这个架构很好？

综上所述，一个好的架构可以从以下几个方面进行评估:

包括：形式、效果和实施三个维度。

评价一种结构形式的第一个原则是：高内聚，低耦合。关键是：内聚的边界在哪里？耦合的边界在哪里？什么样的内聚是高内聚？什么样的耦合是低耦合？有点难把握，所以我增加了一点：明确的责任，明确的关系，高内聚，低耦合一起看一种结构形式。

在分析一个架构时，首先要看每个模块的职责，那么如何才算“职责”呢？

职责：业务中不可分割的原子操作

在判断是否高内聚，职责是否明确时，第一步是先分析职责。我把责任定义为上述形式，在业务上不可分割的原子操作。例如，共享自行车的开始订单操作是一项责任，包括：创建订单、开始收费、解锁等操作。它们是整个业务，其中只有一个对业务毫无意义。此外，这个地方的业务不一定是针对用户的业务，比如一些中间件系统，此时的业务是针对系统功能的。

接下来，列出模块的这些职责，看看是否清楚，然后看看是否内聚。事实上，这些词还是不能客观地给出一个标准，就像计算1+1一样，如果等于2就是对的。这在很大程度上取决于主管的判断。我觉得这个主管的判断可以借助费曼的学习方法，就是把这个系统的职责告诉一个不熟悉这个系统的人，看能不能用最简单的语言描述清楚。此外，从另一个角度来看，内聚背后的驱动力实际上是不同的领域化和分工。因此，如果一个人想掌握这个系统，需要在不同的领域有知识，他必须承担太多的责任。

如果职责明确，客观评价不好，但确实有办法衡量清晰的关系和低耦合：即绘制关系依赖图。因此，一个好的架构师必须能够清楚地了解整个系统的职责，然后绘制一个清晰的关系依赖图，然后从这张图中发现问题，找到优化的方向。

看一个最简单的例子。在关系1中，这是一个更好和理想的情况：模块A单向依赖模块B。如果系统所有模块均为单向依赖，且无循环依赖，则整个系统为分层树，层次清晰。

然后，关系2中经常有大量的依赖关系，这基本上是由于责任不明确造成的：要么将依赖的责任分离到模块C或模块D上，要么为上层C和D提取一个底层模块。

一般来说，从形式上讲，本质上注重责任明确和内聚。然而，有时我们很难给出一个客观的标准来衡量。因此，更多的时候，我们应该梳理依赖关系，理顺关系，发现模块之间的问题，减少耦合，提取或内聚，从整体上实现分层树结构。

无论如何设计，一个架构都可以用作黑盒，从效果上来评价:

有一个前提，就是识别问题。事实上，很长一段时间以来，我认为识别问题是架构师的难点，但根据最近的实践，问题很容易识别，因为现在基本上不是从0到1，或者你独自工作，基本上团队已经扔了一段时间，这次，痛点，问题我们都知道。只是缺乏解决方案。甚至有时我们都知道解决方案，但缺乏实施方案。

解决问题只是第一步，下一步就是体现一个好的架构师的能力:提高效率，降低成本，提高解决问题的效率，降低解决问题的成本。要实现提高效率和降低成本，难点不在于如何衡量:毕竟这个很容易衡量，就看投入的资源了；难点在于设计了一套提高效率和降低成本的方案。本文的重点不是设计，所以大概列出了一些点:

• 模型设计与优化
• 技术引进
• 技术创新：非常困难。

事实上，从直接效果的角度来看，架构增加了责任感，就像建造建筑一样。建造建筑必须比建造草屋更复杂，但前者可以生活更多的人。因此，一个好的结构必须平衡复杂性和收入，最大限度地提高效率，降低成本。

如果一个架构不能着陆，它就不是一个架构。因此，在评估时，还需要对实施计划进行评估。这一块的标准主要从两个方面制定：

• 时间/劳动力成本：这取决于投资多长时间，有多少人来实现它
• 维护成本：不允许拉一票人开放完成，结构后面难以维护，也是一个失败的结构。

所以，总的来说，除了内聚和责任明确，这一块不容易衡量，其他都可以衡量:

• 依赖关系清晰:画一个系统依赖关系图，越细越好。另外，既然是关系，就要有强弱依赖，明确
• 效果也可以衡量:明确设计这个架构能给别人带来的好处，明确不要模糊
• 实施成本也应尽可能衡量：有时实施成本不能准确评估，但在开发过程中发现一些问题。此时，我们应该主动吸引更多的人来讨论是否有潜在的坑，特别是对剩余系统的重建。