SOA/WCF解剖系統和服務的界限

Question

我建立一個系統，這將有幾個渠道餵養不同的客戶端（MonoDroid的，MonoTouch的，Asp.Net MVC中，REST API）

我試圖採用一個SOA架構，並試圖通過可達性模式採用持久性（http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/）

我的問題涉及設計建築。如何最好地將系統拆分爲謹慎的塊以從SOA中受益。

在我的模型中有一個SystemImplementation，它代表了系統iteself的安裝。也是一個賬戶實體。

我最初以爲關於設計這個問題的方法是創建服務：

• SystemImplementationService - 負責管理與實際安裝本身，如品牌，流量日誌等
• 帳戶服務的東西 - 責任用於管理用戶資產（媒體，聯繫人等的網絡）

邏輯上一個新的用戶帳戶的註冊將在AccountService.RegisterAccount發生在服務可以TA ke關心驗證新帳戶（duped用戶名檢查等），哈希pw等

但是，爲了實現持久性的可達性，我需要將新帳戶添加到SystemImplementation.Accounts集合爲它保存在SystemImplementation服務自動（使用nhibernate我可以使用lazy = extra來確保當我將新帳戶添加到集合時，它不會自動加載所有帳戶）

爲了實現這種情況，我可能需要創建帳戶AccountService，將未保存的實體傳回給客戶端，然後讓客戶端調用SystemImplementation.AssociateAccountWithSystemImplementation

因此，我不需要調用th e從AccountService的SystemImplementation服務（因爲這樣，糾正我，如果我錯了 - 是不好的做法）

我的問題是 - 我是否分裂系統不正確？如果是這樣，我該如何分解一個系統？是否有任何方法來定義系統應該被拆分爲SOA的方式？是否確定在服務調用WCF服務：

AccountService.RegisterAccount - >SystemImplementation.AssociateAccountWithSystemImplementation

我很擔心，我要去開建基於一些反模式，這將晚一點趕上我的系統:)

Answer 1

隨着SOA，最難的部分是決定你的垂直切片的功能。

的一般原則是......

1）你不應該有多個服務談話的同桌。您需要創建一個涵蓋功能區域的服務，然後通過防止任何其他服務觸及這些相同的表格來實現嚴格的服務。

2）與此相反，您還希望保持每個垂直分段儘可能窄，但可以是（但不能窄）。如果你可以避免複雜的深層對象圖，那就更好了。

如何切分您的功能取決於您自己的舒適程度。例如，如果您在「文章」和「作者」之間存在關係，那麼您將很想創建一個代表「作者」的對象圖，其中包含作者編寫的「文章」列表。實際上，通過「AuthorService」提供的「Author」對象以及僅從AuthorId獲取「ArticleService」中的「Article」對象的能力會更好。這意味着您不必在每次處理作者時都要創建一個包含文章，評論，消息，權限和加載的完整作者對象圖。儘管NHibernate會爲你延遲加載相關部分，但它仍然是一個複雜的對象圖。

Answer 2

您有分區問題，但您並不孤單，每個採用SOA的人都會遇到這個問題。如何最好地組織或分割我的系統到相關的部分？

對我來說，Roger Sessions正在談論這個話題的最有意義，像微軟這樣的人正在大聆聽。

改變了我的想法的論文可以在http://www.objectwatch.com/whitepapers/ABetterPath-Final.pdf找到，但我真的推薦他的書「複雜企業簡單體系結構」。

在那本書中，他介紹了集合論的等價關係以及它們與服務合約劃分之間的關​​系。

簡而言之，

制訂分區規則可歸納爲五個定律：

1. 分區必須是真實的分區。 a。項目只能在一個分區中存在，永遠不會。

2. 分區必須適合當前的問題。 a。當它們適合於手邊的問題 時，分區僅使複雜度最小化，例如，一家以顏色組織的服裝店對於尋找他們想要的東西的顧客來說幾乎沒有價值。

3. 子集的數量必須合適。 a。研究表明，子集中似乎存在最佳數量的項目，增加更多子集，從而減少每個子集中項目的數量，對複雜度影響很小，但減少了子集的數量，從而增加了子集的數量每個子集中的元素數似乎增加了複雜性。該數字似乎在3-12的範圍內，其中3-1 是最佳的。

4. 子集的大小必須大致相等 a。子集的大小及其在整個分區中的重要性必須大致相當於 。

5. 子集之間的相互作用必須是最小的和明確的。 a。複雜度的降低取決於最小化分區的子集之間的交互的數量和性質。

如果起初你認爲它錯了，那麼SOA的宣言告訴我們，我們應該重視進化改進，追求最初的完美。

好運