平台边界与兼容性

本文总结一下个人对边界与兼容性的理解

系统边界

在系统架构中，经常讨论到”系统边界”的问题，因为这决定了一个系统与外部交互的方式。通常而言，一个设计良好的系统，与外部的边界应该是清晰并且相对封闭的，这样系统与外部就不会存在过多的耦合，这个系统可以比较容易地演进，而不用担心对外部产生意料之外的影响。

举例来说，下图的系统边界就是比较清晰的：

系统A暴露了3个接口，分别是A，http接口；B，RPC接口；C，异步消息（即会侦听特定格式的消息），那么外界对系统A的依赖，就只有这3个接口。无论系统A如何演进，包括改变内部的逻辑、数据结构等，只要这3个接口的格式和行为保持不变，那么就不需要担心对外部造成任何影响。

反之，如果系统A不是通过接口的方式暴露数据存取能力，而是允许外部直接访问数据库执行SQL，那么系统A的边界就错误地过分暴露了。系统设计者无法确定外部是以何种方式操作数据库，可能会依赖哪些字段，那么后续修改数据结构会造成多大影响，就无法做出准确的评估了。

因此边界对于系统的长期演进具有重要的意义。边界就是系统被外部依赖的部分。依赖是双向的，系统会被别的系统依赖，同时也会依赖外部的一些接口。边界指的应该是被别人依赖的那一部分。

平台边界

如果将系统边界的概念延伸一下，平台的边界也是类似的。最近两年做的产品是一个低代码开发平台，由若干个微服务组成。在平台之上，用户使用平台的能力，开发自己的应用。

在这里，平台能力的总和，就是平台对上层业务的边界。比较容易识别出来的是平台提供的API接口，但是除此之外还有一些其他的边界，比如平台提供的UI组件库、开发SDK、DSL语言、基础模型等。

兼容性

识别平台边界的最终目的，还是为了长期的兼容。其实兼容理论上也很容易，只要保证”保持边界不改变”即可。这里面主要有2个问题，第一个是将边界识别出来，第二个是有一定的技术手段或者管理手段，确保边界不被修改，否则就变成了一句空话。

其实平台和其上的业务，是否一定要保证兼容，很多时候是博弈的结果。比如说iOS，作为一个非常成功的平台，也是非常强势的，有几次iOS大版本的升级，其实都没有做到完全兼容，修改和删除了很多iOS SDK中的API，很多APP都无法正常运行了。但是由于iOS平台相对于APP的开发者，是更有话语权的一方，所以开发者也只能修改APP重新上架。

反过来，windows在兼容性方面就一直都做得非常好，许多win95上的应用，在windows vista上还是可以正常运行。

通常而言，大部分的平台产品都不能跟iOS和windows相提并论，所以一般来说是需要保持兼容的。