面向服務的體系結構和域驅動設計

我一直以SOA類型的方式開發代碼。今年我一直在努力做更多的DDD，但我一直覺得我沒有得到它。在工作中，我們的系統負載均衡，並且設計爲不具有狀態。該架構是：面向服務的體系結構和域驅動設計

網站

===物理層==

主要服務

==物理層==

服務器1 /服務2 /服務3 /服務4

只有服務器1，服務2，服務3和服務4可以與數據庫交談，主服務根據訂購的產品調用正確的服務。每個物理層也負載平衡。

現在，當我開發一項新服務時，我嘗試在服務中考慮DDD，即使它並不真的覺得它適合。

我用好DDD原則像實體，價值類型，資料庫，集料，工廠等

我甚至一直在使用ORM的嘗試，但他們似乎只是沒有像他們適合在一個無狀態的架構。我知道有解決方法，例如使用IStatelessSession而不是使用NHibernate的ISession。但是，ORM只是覺得他們不適合無狀態的架構。

我注意到我真的只使用DDD教給我的一些概念和模式，但整體架構仍然是SOA。

我開始認爲DDD不適合大型系統，但我認爲某些模式和概念確實適合大型系統。

就像我說的，也許我只是沒有抓住DDD，或者我可能在分析我的設計？也許通過使用DDD教會我的模式和概念，我正在使用DDD？不知道這篇文章是否真的有問題，但是當我試圖弄清楚DDD在整個系統中的位置以及它的真正可擴展性時，我有過更多的想法。事實是，我不認爲我真的知道DDD是什麼？

來源

2010-03-18 null_pointer

有關領域驅動設計中最重要的事情是大局觀念：

通用語言，
的戰略決策，你是通過在覈心領域工作增加值（和將自己與其他討厭的系統隔離開來），以及通過將基礎結構與業務邏輯分離來製作可測試的靈活設計的方法。

這些是廣泛適用的，是最有價值的作品。

關於工廠，服務，存儲庫，聚集等有很多設計模式的東西，我把這個建議從一個有經驗的開發人員轉移到另一個，而不是福音，因爲它的大部分可以根據您正在使用的語言和框架。因爲像我們這樣的程序員是面向細節的，我們對這種東西很着迷，所以他們往往被過分強調。那裏也有寶貴的東西，但它需要保持透視。因此，其中一些可能與你無關，或者隨着你的使用而增加。

所以我想說這不像是你可以通過確保你使用所有模式的清單，這是一個牢記大局的問題，並且看到如何改變你開發軟件的方法。如果你從模式中選擇一些好的提示，那也很棒。

特別是關於SOA的事情，我開發的應用程序將所有狀態都推遲到已使用持久性無關域對象的數據庫。編寫測試服務必須嘲笑daos並回饋東西是苦差事，我可以把更多的邏輯放在域對象中，我不得不在服務中嘲笑嘲笑，所以我傾向於更好地使用這種方法。

來源

2010-04-16 19:03:10

我認爲一個常見的誤解是，SOA和DDD是兩種衝突的風格。

IMO，他們是兩個共同工作的概念; 您可以創建封裝域概念的域模型，並通過服務向該模型公開入口點。

我也沒有看到ORM和服務有什麼問題，您可以輕鬆地使用每個服務調用的session/uow。只需將您的服務操作建模爲原子域命令即可。

一個簡單的例子：

[WebMethod] 
void RenameCustomer(int customerId,string newName) 
{ 
    using(var uow = UoW.Begin()) 
    { 
     var customerRepo = new CustomerRepo(uow); 
     var customer = customerRepo.FindById(customerId); 
     customer.Rename(newName); 
     uow.Commit(); 
    } 
}

也許你所面臨的問題是，你創建了「UpdateOrder」這需要一個訂單實體，並試圖在新的會話來更新這個服務？

我儘量避免那種服務，而是將這些服務分解爲更小的原子命令。

每個命令都可以作爲一個操作公開，也可以有一個服務操作接收命令組，然後將這些命令委託給命令處理程序。

IMO，這樣你可以更好地暴露你的意圖。

來源

2010-05-06 08:45:14

我覺得這絕對是美麗的。 – 2010-08-12 00:43:32

我終於提出了一些關於此的帖子：服務+命令模式+ DDD http://rogeralsing.com/2013/12/02/using-command-pattern-to-capture-language-and-intent-for-服務/ – 2013-12-03 10:27:37

有些信息爲什麼舊的DTO方法不好http：// rogeralsing。com/2013/12/01/why-mapping-dtos-to-entities-using-automapper-and-entityframework-is-horrible/ – 2013-12-03 10:28:04

DDD中引入了一些概念，在構建SOA時實際上可能會讓您感到困惑。

我不得不完全同意another answer，SOA服務公開了充當原子命令的操作。我相信一個非常乾淨的SOA使用消息而不是實體。然後服務實現將利用域模型來實際執行操作。

但是DDD中有一個叫做「域服務」的概念。這與應用程序服務稍有不同。通常，「域服務」的設計與域模型的其他部分使用相同的無處不在的語言，並且表示業務邏輯不適合實體或價值。

域服務不應與應用程序服務混淆。實際上，應用程序服務可能很好地實現，使其使用域服務。畢竟，應用程序服務可以完全封裝SOA中的域模型。

來源

2010-08-12 00:50:05

面向服務的體系結構和域驅動設計

回答

相關問題