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還沒有提供這種功能。