DDD還有一個問題。考慮堅持我的總量（我不希望使用事件採購）我在互聯網上搜索，發現非常有趣的Vaughn Vernon的article。簡而言之 - 作者讚揚使用面向文檔存儲的整個結構存儲域對象的概念，特別是PostgreSQL。DDD - 在面向文檔的存儲中存儲域對象，PostgreSQL，MongoDB
我的問題是 - 因爲我是DDD概念的新手 - 在DDD開發中使用這種方法常見嗎？我的意思是使用面向文檔的存儲將集合存儲爲序列化的完整文檔？ 我認爲持久聚合他們的嵌套方式更接近DDD的想法，比加載它和使用ORM映射。對於域對象的嵌套結構，文檔格式似乎更自然，更具彈性。 除了上面提到的文章，我沒有找到關於這個概念的更多評論。
接下來的問題是 - 在PHP環境中 - 有沒有人試圖將它與Doctrine2綁定？看起來它可以自動序列化POPO，並且可以使用ValueObjects某種方式。
在此先感謝！
我的問題是 - 因爲我是DDD概念的新手 - 在DDD開發中使用這種方法常見嗎？
是 - ish。
有一點要記住：DDD旨在幫助正確建模業務。如果更改對於域有寶貴的財產（可能是這種情況下，如果這個項目是一個代表您的業務競爭優勢的項目），那麼您需要考慮可輕鬆遷移到改進模型的彙總序列化。換句話說，您如何將舊模型的表示映射到新模型？
如果你正在採取這種方法，那麼你可能也想看看cqrs;數據斑點對於寫入用例來說是令人滿意的，但只寫域模型並不能提供很大的業務價值。您可能更容易開發最終一致的讀取模型，而不是試圖根據文檔存儲的需求構建複雜的預測。
您看到類似方法的另一個地方是使用事件源聚合的解決方案;寫入是通過追加歷史來實現的，並且涉及任何給定更改的實際狀態通常存儲在blob中。
正如您在本書中可能知道的那樣，聚合持久性是通過使用Repository模式完成的。其目的是隱藏域模型中的持久性技術和實現細節。
根據定義，存儲庫只能存儲和檢索整個聚合。這就是爲什麼弗農提到文件類存儲是一個很好的候選人。在使用RDBMS進行聚合持久化時，通常最終會使用ORM和複雜映射。當走這條路，你會得到複雜的模式，而不是最優的查詢，繁瑣的更新邏輯等等。
這確實是CQRS特別在DDD社區獲得牽引力的原因，因爲傳統的「收集風格」存儲庫缺乏查詢許多彙總和檢索某些「報告風格」數據的能力。藍皮書提出了一些相當複雜的方法來做到這一點。 CQRS消除了這個問題，但需要相當多的額外工作來保持兩個模型的同步。
還有另一種方法來處理它。通常，域模型不需要對聚合運行查詢。域模型的「客戶端」負責向域模型發送適當的「命令」或請求，以便由某種應用服務處理。六邊形體系結構中的這個「客戶端」部分或「適配器」部分可以在不使用任何存儲庫的情況下在域持久性數據庫上運行查詢。它也是一種CQRS，但使用一個數據庫。