世界是复杂的，很多东西难以直接获取。
例如直接最强幸福，是永远追不到的（《乐在工作》一书中说幸福是副产品）。
殊不知，合理的接口设计也不是“直接”得到的。
由于面向对象非常强调“自治”，许多人不知不觉的形成了一种错误认知：面向对象推崇“我的接口我做主”。很遗憾，“自治”正确。但“我的接口我做主”这个推断是错误的。
软件世界中本无模块。1968年，Dijkstra发表了第1篇关于层次结构的论文《The Structure of THE-multiprogramming System》（原文PDF）。1972年，Parnas发表论文《On the Criteria To Be Used in Decomposing Systems into Modules》论及了模块化和信息隐藏的话题......这是架构学科开始萌芽的标志。
那么，为什么要对软件进行模块化设计呢？是为了解决复杂性更高的大问题。于是，我们突然领悟：对问题进行分解，分别解决小问题，其实这只是手段。每个架构师应该牢记：
“分”是手段，“合”是目的。不能“合”在一起支持更高层次功能的模块，又有何用呢？
因此，我们必须把模块放在协作的上下文之中进行考虑。架构师设计接口时，要考虑的重点是“为了实现软件系统的一系列功能，这个软件单元要和其他哪些单元如何协作”，总结成一句话就是：
协作决定接口
相反，直接设计接口，是很多“面向接口的”架构依然拙劣的原因之一。类似“我的接口我做主”的观点是错误的，每个模块或子系统（甚至类）无视协作需要而进行的接口定义很难顺畅的被其他模块或子系统使用。