一个系统肯定会包含多个类，无论我们怎么组织这些类，降低组件之间的耦合度，不同组件之间还是存在一些关系，如关联、继承或依赖关系。在组件层次如果认为两个组件之间的类存在关联、继承或依赖关系，那么我们认为两个组件之间就存在依赖关系，这种组件间的各种关系我们统称为依赖关系。

哈佛商业评论Lee Fleming和Olav Sorenson两位专家关于组件化（模块化）对产品开发创新的影响所提出的研究，其中特别强调组件间的依赖是成功的关键因素。
“The process of innovation is,virtually by definition,filled with uncertainty; The interdependence of components has an enormous effect on the pace and complexity of the innovation process.”

“In modular designs,changing one component has litte influence of others or on the system as a whole.”

“Consider the ink-jet printer;First proposed by Loard Kelvin in 1867,it took more than a hundred years to become commercially viable,even after millions of dollars of investment by …”

“The culprit：servere interdepenence of the components,including the chemistry of the ink,the physical layout and composition of the resistors,and son on.”

“Our research indicates that intermediate levels of interdependence produce the most useful inventions.”

上面举例了索尼公司采取高度标准化及易于更换的组件迅速设计出市场极受欢迎的随身听。也举了喷墨打印机因为组件间的高度依赖，在研发100多年后才开始商业化。

调查得出的结论是：

适度的依赖能产出最有用的新产品。

Jack Harich说到：
“Sadly enough,most software is shedule or requirements driven. Better is architecture driven(or centric),where the architecture is designed first and product second… Software should be architeture driven,while projects should be risk driven. When looking at an unfamiliar piece of software,the first question to ask is ‘Is it architecture driven?’ I adopted this philosoply from Grady Booch”

遗憾的是，多数软件系统开发是采取时间驱动或需求驱动。比较好一点的是采用架构驱动，这种模式是架构的设计在先，然后才在该设计的规范下进行系统的构建。······软件应该是架构驱动，项目应该是风险驱动。当看到一个新的软件系统时，首先就该问：它是架构驱动吗？我的这种思维来自Grady Booch。

UML component一书中写道，我们期望在组件持续演进及需求不断变化的环境之下，仍然能够对整个系统做出妥善的管理，我们应当重视系统的架构。

在一切事情都快速变化的今天，组件化设计的首要目标是：能够轻易地更新与置换，以长保系统的优势。

那么组件化软件开发想要解决软件开发上的哪些问题？
那就是管理变化。应变能力是系统构建的首要考量，进行系统架构和设计时，必须特别注意组件之间的依赖，以及依赖的管理。