Spring和AOP像一個強力的粘合劑，將完全獨立開發的組件（或說是模塊，下同）粘合成一個有機的，完整的，可擴展的系統。正是有了這個粘合劑的幫助，才實現了比較徹底的獨立組件開發。
說它是“比較徹底”，是因為它極大的減少了組件之間的依賴。在你開發一個組件時，基本上不會因為其它組件沒有開發完成，或出現Bug而影響到你的進度。
但是，它并沒有完全消除開發時組件之間的依賴，你仍然得依賴于其它組件提供的API接口。為此，我們不得不把一個組件拆成兩個jar包：一個component-api.jar，一個component-impl.jar。由于api包內全是公用接口和Value Object，所以它相對穩定，可以早早的提供出來。這樣，一個組件如果要使用另一個組件的服務，在開發階段，只須依賴于api包即可。運行時，Spring再根據服務提供組件的配置信息找到正確的實現類。
昨天，我們在一個討論會上發現了一個有趣的問題：
組件UIA是一個UI組件，它要求提供一些數據，于時它把自己的要求寫時接口ProviderA中。組件C1和C2是兩個不同的業務組件，它們的UI中都有使用UIA這個組件，而它們都提供了自己的數據接口ServiceC1和ServiceC2。
ProviderA所要求的方法，在ServiceC1和ServiceC2中都有提供。這個時候怎么做才能使各個組件完獨立呢。
一、讓ServiceC1和ServiceC2繼承于ProviderA。但是這樣將導致業務組件依賴于UI組件。有誰知道一共有多少個UI組件需要依賴啊？而且UI組件是最易變的。
二、把ProviderA從uia.jar抽出來，放到單獨的uia-api.jar中。這個就未免小題大做了。一個系統少說也有幾十個UI組件，難道要生成上百個jar包不成？
三、把所有的UI的要求的API都抽出來，放到一個ui-api.jar中。這樣jar包是少了，可是單個的UI組件就失去獨立性了。
上面三個方案，不管怎么管理UI組件的接口，都沒有解決業務組件依賴于不定數目的UI組件這個問題。
最后，我們采用的方法是：把UI組件視為某個業務組件的子組件，UI組件自己不定義接口。所有對外的接口和對UI的接口，都放在業務組件的api包中。
這樣做，業務組件和UI組件都依賴于api包，互相之間沒有依賴。當然，這樣做，UI組件就不能游離于大的業務組件之外。而我們采用這個方案的原因也在于，我們認定為多個組件提供服務的UI組件是很少的。
顯然我們采用的方法只是就事論事的一個折衷方案。并沒有解決服務提供者和消費者之間的交叉依賴。
要解決這種交叉依賴，我的思路是再提供一個接口之間的粘合機制。消費者定義自己要求的服務接口，提供者定義自己提供的服務接口。最后用一個配置文件，將二者粘合起來。
目前，Spring還沒有提供這種功能。