如何設計鬆散耦合的系統，這些鬆耦合的系統通常可能需要來自彼此的數據，但不一定屬於同一類別？關於設計鬆耦合完整系統的建議？
例如，讓舊的Pet-shop示例更進一步，並創建寵物店專營權。每家寵物商店都有自己的網站，列出他們的聯繫信息，促銷活動和當前庫存。
特許經營店主想要列出所有特許寵物店以及聯繫信息，並可能在其公司網站上提供一些照片。他們希望能夠更新這些信息，並且可以自動雙向推送任何更新。他們還希望以自動方式向所有商店的網站提供促銷信息。
因此，在這種情況下，庫存清單由商店「擁有」，聯繫信息由兩個實體「部分擁有」，並且促銷信息由總部「擁有」。由於任意原因，所有這些數據不能存儲在同一個地方。
是否有一些最佳實踐或常見策略來應對這種情況？
我一直在思考這個問題，並且我表達了類之間的關係是上下文確定的。任何假定全局靜態關聯（固有耦合）的模型都是有問題的。
我喜歡使用的另一個示例是Products。
產品可以扮演一大堆不同的角色。它與OrderItem相關聯，OrderItem與與客戶關聯的訂單相關聯。
它由供應商提供。
它在目錄中，也許按章節和頁。
這是買方的責任，有多個供應商提供。
處理這種複雜性的能力很容易就是關係數據模型的根本好處;而且我還沒有看到它在面向對象方面的處理。
另外：還有另一個ORM（對象角色建模，參見VisioModeler，InfoModeler等），它非常有用地查看關係方面的問題（恕我直言）。
當你將自己與數據庫的關係性隔離（通過使用CRUD生成器，ActiveRecords等）時，你隱藏了這一重要方面。（我認爲LINQ有同樣的問題，以及引入基本的耦合問題，但我還沒有完全解決它）
我認爲你可以成功地通過它的方式，如果你小心，但是在設計中嵌入耦合變得很容易，特別是當你從數據庫返回到應用程序的其餘部分時，而不是其他方向時。
我的理解是，這種問題通常是使用稱爲「數據聯邦」的技術來解決的 - 獨立實體獨立運作，但存在一個傘狀實體，提供將系統視爲整個。
這裏有一篇文章，可能是有用的： http://www.soamag.com/I22/0908-1.asp
在規劃架構，記住，當參與者之一是不可用會發生什麼。例如，我會建議將促銷信息複製到所有商店，無論是作爲批處理進程還是參考數據更改時。這樣，如果網絡出現故障，各個商店仍然有促銷信息並可以運作。
看來SOA在這種情況下可能會有幫助。我特指具有業務級別的SOA，如Bill Poole和Udi Dahan帶有pub-sub異步事件的實現。
您描述了幾個業務職能與單獨的所有者：特許經營和銷售。你想要實現它們之間的鬆散耦合。
在SOA方式中，您定義了特許經營服務以及多個銷售服務實例，每個商店都有一個實例。商店最初非常相似，但可以分開進化。
然後定義這些服務中發生的共同感興趣的商業事件。特許經營服務可以發佈所有銷售服務訂閱的NewPromotion事件。此事件消息包含有關促銷的所有詳細信息，消費者會選擇他們需要的內容銷售服務輪流發佈ContactDetailsChanged事件以供特許經營使用。
每個服務都有在裏面自己的多層次的實現，完成與數據庫，面向客戶的網站，與其他系統等
每個服務店私下一切感興趣的私人數據集成點：庫存清單，聯繫信息，促銷信息 - 以它認爲合適的形式。一項服務中的信息更新通過事件傳播到其他服務。
在實現方面，您需要某種服務之間的服務總線，支持不可靠的互聯網上的持久消息，例如， NServiceBus。沒有必要的WebServices（TM）。
您的服務在實現中鬆散耦合，因爲它們只共享合同（它們發佈的消息和端點的描述），並且可以獨立演化內部表示。它們也是及時鬆散耦合的，因爲如果它們在任何時候都不會互相發送可以通過互聯網超時的同步請求。所有消息都由基礎設施（服務總線）處理。
希望這會有所幫助:)
我主要同意上面提出的解決方案（使用SOA）。取決於應用程序的複雜性，ESB可能是一個好方法。但是，我認爲ESB佔用的空間很大，並且爲大多數真實世界的應用程序帶來了不必要的複雜性。
但是，恕我直言，任何好的架構應該很容易適應應用程序服務器，無需進行重大的架構/設計更改。
假設一個基於Java的中大型規模的n層應用程序，這裏是我的中間層和EIS層的建議：
分隔各個子系統的實現和揭露它的功能通過一個服務接口並隱藏實現直接使用或引用。
爲每個子系統創建一個JAR（或EAR）文件，並確定上述子系統/ JAR之間的運行時間和編譯時間依賴性。
花費大量時間來確定服務接口方法和子系統依賴關係的正確粒度。
在此過程中，嘗試爲每個模塊標識DAO層（假定涉及到數據庫）併爲每個子系統分隔數據庫表。
對於網絡層，請嘗試按照以上方法通過由子系統對錶示層進行分區來執行上述操作。爲每個子系統創建一個WAR文件。如有必要，嘗試將表示層WAR放入上面標識的相應EAR文件中。
上述體系結構的一個很好的驗證就是在OSGi中使用每個服務作爲OSGi服務（在創建適當的清單文件之後）部署它。
請記住，如果需要，也可以在任何這些子系統之間設置基於事件/異步通信。
這提供了一個拆分子系統的機會，並將它們部署到服務器的不同服務器場中，以獲得更好的可擴展性機會。
祝你好運..！
我認爲你可能會找到一本書（[在線查看]）（http://books.google.co.uk/books?id=9CL446IzhuAC&pg=PA38&lpg=PA38&dq=events+chapter+one+coupling&source=bl&ots= qmJTOuCz90與SIG = EZKvZBjF8QmGohatC97HsmAqG0c＆HL = EN＆EI = wj6tTqe5LcTX8gON_YyiCw＆SA = X＆OI = book_result和CT =結果＆resnum = 6＆VED = 0CEMQ6AEwBQ＃v = onepage＆q =事件％20chapter％20one％20coupling＆F = FALSE）） 「基於事件的編程：服用事件到了極限 」 別拿面值的題目 - 第一章給出了一個有洞察力的描述和方法，以減少/轉移耦合到較少形式的耦合行爲。 – 2011-10-30 12:23:08