通过多进程，我们可以实现业务逻辑的动态组合。但是用普通函数也可以组合
function f(g: () => void) {
// do something
g();
// do something else
}这样 f 和 g 就组合起来了，我们称 g 为一个插件。 插件边界是指当 f 和 g 来自于不同的 git 仓库的时候，f 调用 g 就是跨越了 git 仓库的边界。 那怎么能实现 f 和 g 来自不同的 git 仓库呢？
- 动态二进制链接：windows 的 .dll，linux 的 .so
- 动态源码链接：javascript 可以远程下载 js 文件，然后动态执行
- 静态二进制链接：windows 的 .lib，linux 的 .a 或者 .o
- 静态源码链接：webpack
一些运行时环境，例如 iOS 是不鼓励从网络动态加载代码的。 插件并不一定等于动态化，插件完全可以是静态装配的。
无论代码是怎么组合成运行时的进程整体的，拼装后总是有拼接缝的。 那我们就可以在“插件loader”这样的地方去添加打日志与监控的代码。 并不是 RPC 调用才有错误率，请求延迟这些指标。插件也可以有。
虽然函数调用的频次是非常高，暴力记录所有的函数调用是吃不消的。 但是我们完全不用关心 Array.map，Set.add 这样的函数被调用了多少次， 只需要区分好哪些是插件，然后把这些高价值的插件函数给监控好就足够提供 Feedback 了。 不同 git 仓库的所有者，仍然可以从日志里拿到自己的日志，和进程隔离没有区别。
如果有强制的插件规范，那甚至可以做到“内存状态”的隔离，用编译检查等手段禁止全局变量，禁止偷偷地访问另外一个插件的内部状态。 一个进程要读取一份配置，只有第一次RPC的时候我们才能监控到，后续缓存在内存里的访问就是不可见的了。 而插件则不用担心跨插件调用的开销，我们可以把配置缓存在另外一个插件里，这样每次读取配置都是跨插件的调用，从而可以被监控到。
插件和进程的核心区别就是插件可以适用于更多的运行时（比如iOS，微信小程序），可以用于拆分运行时调用关系更频繁更紧密的界面和流程。 进程边界的优势来自于社区共识，提前提供了大量开源的优秀基础设施。 但是并不意味着，除了进程边界，我们不能在进程内再为每个 git 仓库划出边界来，只是要付出一些自研代价罢了。 社区共识是不够的，在函数边界（特别是同步调用栈之外的其他调用关系），以及插件边界上都没有足够强的规范。 只要能在公司或者部门级别建立好共识，函数边界和插件边界完全可以满足问题定位的需求，甚至比进程边界做得更好。
那么真正的障碍是什么？是变更自主性，变更的粒度和权责问题。这部分在控制变更里讨论。