【变与不变】架构中的边界划定

在【将原则纳入到架构的生命中】中简单了谈了些原则的重要性，但是原则只能作为我们衡量和评估我们架构的工具。在实际设计一个模块或者系统时，我们又该怎么做呢？那么今天就让我们来看一下架构中的边界划定。

我们在设计一个系统或者模块时，我们知道是我们最终需要实现什么功能，但是我们实现功能的方式后很多中，我们最简单的就是直接编码，自顶向下的编写我们的代码。但是我们都知道这样带来的后果是我们的代码耦合度会非常高，一旦后面有任何改动，都可能牵一发而动全身。所以我们架构设计中的一个重点就是解耦。

解耦就意味着要将我们的代码分开，分成各个模块。这种我们又称为边界划定。模块划分的越细，耦合度就会越低。但是同时导致代码的复杂度变高。可以说这是一把双刃剑，具体划分到什么层次就变成了架构中的一道关键问题。

这个问题在我看来就是区分代码中变和不变的情况，这里的“变”是指两个模块之间是否同步改变，如果同步改变，也就意味我们没有必要将两个模块分开（至少暂时不要），这样我们可以进一步降低代码的复杂度。而如果一个模块的两个部分可能出现不同步改变的情况，那么我们就要考虑是否要将模块拆开，进一步降低两者的耦合度。

这个“变和不变”的判定并不是一蹴而就的，会随着我们对于业务和代码等多方面的理解进一步加深。这里我来谈谈我的理解：

一般来说，当我们拿到需求或者任务的时候，我们首先知道的是我们要实现什么功能。这个时候我们可以根据功能来划分边界。可以粗略，可以详细。不用担心设计不合理或者过度设计，我们需要的就是锚定一个大致的范围。

当我们按照需求划分模块结束后，我们得到了一堆模块。那么接下里我们就要评估各个模块了，评估一个系统或者一个项目，一般采用三个角度，即“可靠性，可拓展性和可维护性”。那么我们就先说一下如何用这三个方面来改进我们的架构。

可靠性意味着系统的健壮性，也就是即使我们的系统发生故障，也能正常工作。这听起来很厉害，但是实现上我们简单考虑这两种方式：监控和防护，监控就要求我们尽量增加一些模块来帮助我们理解运行的情况。防护包括安全设置和状态恢复。这也需要增加额外的模块。

接下来是可拓展性，也就是代码适应以后的变化，这个是门大学问，也值得我们单独来说。不过在这里我简单说一下，所谓的适应以后的变化，我们简单考虑这两种方式：降级，拓展（水平拓展和垂直拓展）。降级就要求我们模块划分时要考虑多级服务，当资源不足时，那些服务需要保证，那些可以舍弃。这个角度就可以将模块做进一步的划分或者组合。拓展我们这里主要考虑水平拓展，也就是俗称的加机器。垂直拓展是指部署在更高性能的机器上，这个不需要服务有什么要求。那么水平拓展就要求我们考虑我们的模块哪些可能是瓶颈，我们尽量将瓶颈变成可以水平拓展的，也就一般所说的无状态。这要求我们对模块进行进一步的拆分。如果我们有多个模块会一起出现瓶颈，那么我们就可以将服务进行组合。

可维护性意味着代码要足够简单。因为简单就意味着以后无论修改还是修补成本都会很低。那么如何让代码变得简单呢？我们一般可以思考这样几种手段：第一是抽象，这个可能要求我们增加一些不同于需求模块的模块，这些模块存在的意义就是屏蔽我们的具体实现，而提供一个统一的接口供上层使用。另外一个就是统一标准，也就是在同一层我们采用的规则或者结构尽量一致。第三就是说明要详细，如果我们的模块无法从表面看出是什么作用，那么就一共要增加相应的辅助模块，即使不是代码也可以。

当我们从这三点评估完后，我们得到了一个需求和技术相结合产生的架构。可以说架构的基本范围已经划定，接下来就是用设计原则来评估我们每个模块是否划分正确。但更为重要的是我们需要配合其他人一起评估我们的方案，因为自身的思维局限，所以我们更需要从别人的观点来完善我们的架构。