架构的灵活扩展性核心在于面向抽象设计

架构的灵活扩展性核心在于面向抽象设计

阅读引导：

1、程序架构的灵活扩展性，核心在于封装变化

2、封装变化，最主要的手段就是将变化抽象

今天聊一聊架构设计的灵活扩展性。

老规矩，还是来看一下定义：

扩展性（Extensibility），指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。

表现在系统的基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。是系统架构层面的开闭原则，考虑未来功能扩展时，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。

1

常见实例

我们常见的例子，程序员经常使用的eclipse平台，还有非常火爆的 VS Code，都是使用的“微内核+插件”的方式，支撑了无比丰富的生态。

在任何一个平台上，安装了对应的插件以后，可以做相应领域的开发。

很显然eclipse和VSCode的设计理念，是面向插件设计的思路。

这个“插件”是一个抽象的概念，是一套标准，任何实现了这一套标准的实例，都可以发布后在平台上应用。

实际上，我们开发过程中，也一直使用很多标准。

一个例子，日志领域的SL4J是一套标准，然后logback、log4j是具体的实现。

但是这些内容，都是已经非常完善的技术组件了，大家只要去使用就行。

在设计一个新产品的时候，有没有需要面向抽象设计的地方呢？

当然有，并且还是一个原则。

2

封装变化，面向抽象

这个原则很简单。

一切可能有变化的地方，都要封装起来，抽象出来共性。

也就是所谓的面向抽象设计。

因为一旦将可能变化的地方封装起来，用一个虚拟的“对象”替代，对于系统的主流程来说，就不用关心具体的个性化实现了。

可能变化的地方，可以使用策略模式、SPI等方式去实现调度。

例如，一个收费节点，现在以及将来可能有多种收费模式，那么对于收费的模块是不是就要封装起来，做成扩展点？

再例如，一个消息通知模块，通知方式多种多样，例如短信、微信、app消息、邮件、为了的5G视频短信等，且有紧急、非紧急等分类，是不是也会千变万化，非常适合封装起来，做成扩展点？

设计扩展点之后，一旦有了新的模式变化，主流程程序不需要改动，直接新增处理策略即可了，快且不影响存量。

另外，在实际工作中，策略模式是非常常见的一种模式，是对扩展点非常好的而一种实现方式。

3

不明显实例

上面说了很多明显的例子，大家只要有意识就能考虑到。

再举一个例子。

在设计一些需要审批流的系统时，需要设置审批人。

此时，注意点就来了。

我们都知道，这方面一般设计人、角色、权限几张表，也是比较通用的方案。

但是有一个细节点，如果需要任务分配的时候，不要直接去查人员表的岗位，直接分配成处理人。

而是还有通过角色反查来关联。

否则一旦发生变化，程序就变成了写死处理，失去了灵活性。