消息耦合还是接口耦合

最近公司准备开发一个新产品，需要重新设计一套新的框架，但是就这框架中各模块的通信方式，大家产生了争论，主要集中在各模块的交互方式是消息耦合还是接口耦合。

需求大概这样，我们需要封装一套客户端SDK, 暴露一系列API给外部用，而这套SDK内部会有很多模块组成，这些模块之间相互会有交互。

第一种设计是基于接口耦合，框架如下:

 

经过上面的比较， 我们可以得出一些结论：

消息方式的强项是耦合性和扩展性，以及监控的方便性，个人感觉比较适合于Server端的大规模应用。
接口方式的强项是性能高效以及开发的方便性， 比较适用于同一进程内客户端的小规模应用。

但是大部分时候， 对于架构师或是公司领导，他们会更关注可耦合性和可扩展性，所以他们会倾向于选择消息方式，尽管有时可能不是那么适用。

另外，个人觉得编译时静态类型检测是C++的优势，能让我们高效而可靠的开发程序，我们不应该放弃这些优势而去把C++当作弱类型的动态语言来使用，我在  一文也有相关描述。

最后，对于该框架的设计，其实我个人倾向于上面2种方式的结合， 即各个模块的入接口（调用接口）走接口方式，而各模块内部触发的事件走消息总线的方式，虽然没人采用这种方式，还是在这里记录一下。

一个多月了，消息还是接口，领导们老大们关于走何种架构还在争论中， 我等小兵就默默等待吧 ...

呵呵，不知道各位看客会作何选择？