我很努力與我的閱讀模型，因爲它是一種混合域邏輯和讀取模型。想象一下獲得酒店或航空公司的報價。在我的例子中，它正在出貨。要獲得報價，您需要閱讀現有的費率表，然後計算費率。您可能會將此日誌記錄爲報價，最終變成訂單，但獲取的報價部分本質上是讀取，其中包含一些邏輯（即獲得當前燃料費率的服務）以計入費率。彙總將是一個報價。閱讀模型在域
那麼你會使用讀取模型來獲取合同/費率表，並將其映射到域？請記住，讀取將被優化，它不僅僅是一個簡單的GetByID ...並且最好來自讀取存儲庫以獲得性能。
那麼你會使用讀取模型來獲取合同/費率表，並將其映射到域？請記住，讀取將被優化，它不僅僅是一個簡單的GetByID ...並且最好來自讀取存儲庫以獲得性能。
在設計上，聚集應該不需要與任何模型狀態的總邊界之外立即一致 - 「下一個」狀態是當前狀態的功能，參數傳入在其他。單詞，理想化的聚合根本不依賴於所讀取的模型，並且不涉及其中參數的狀態來自哪裏的。
這意味着如果您正在努力「當我在此彙總中編寫報價時，如何從該彙總中獲得當前匯率」，那麼某件事是非常錯誤的。
但是，如果你不需要立即一致性（在大多數情況下，你不需要），那麼有很多可能性。
最直截了當的是，客戶端從讀取模型獲取它需要的狀態，然後將該狀態傳遞給寫入模型。將狀態加載到命令中避免了「混淆」，這是REST取得如此成功的原因之一。
在某些情況下，您會希望模型其他部分的「最近」狀態更加及時。在這種情況下，您可能更喜歡應用程序在將更改提交給聚合之前，代表客戶查詢模型。完全合理。
在某些情況下，您會希望聚合本身執行查詢。實現此目的的最常見方法是通過域服務：將查詢對象傳遞給聚合，聚合使用適當的狀態調用查詢，獲取答案，然後自行選擇如何將結果應用於其目前的工作。
在所有這些中，您從模型中返回的狀態是最近的，不一定是當前狀態。例如，不能保證模型的其他部分當前沒有以查詢結果會發生變化的方式進行更改。
請注意，在所有這些情況下，調用者（尤其是聚合）與域服務提供的計算細節完全隔離 - 域服務是唯一需要知道從寫入模型計算返回率，從讀取模型計算得出，或從緩存中提取。
我的問題是我應該從域內訪問讀取模型，然後將這些映射到域對象。
不可以。編寫模型應該只與它自己的狀態及其參數交互。如果您需要在讀取模型中查找數據以處理命令，則其中一個參數應該是域服務接口，其中域服務的實現執行查找並將結果轉換爲域對象。
我明白你在說什麼，但在REST帖子中傳遞狀態是不現實的。在這種情況下，我並不擔心與其他國家的一致性。我的問題是我應該從域內訪問讀取模型，然後將它們映射到域對象。這是爲了提高性能，因爲通常情況下，您可以通過id獲得聚合，這是來自優化的只讀存儲的速度較慢。 –
另一個例子是操作和用戶設置。您不需要在後期傳遞這些信息，您需要從數據庫/緩存（回購/讀取模型）中獲取這些信息，然後根據這些信息執行業務邏輯。 我得到你的聚合應該有一個屬性，說一個操作列表，但如何加載是一個問題。 –
如果引號是您的域模型中的第一類實體 - 並且沒有非凡的證據，我會期望它們是 - 然後生成一個報價就是寫。 – VoiceOfUnreason
是生產它們是寫，但得到生產它們所需的信息是一個問題。這可能適用於任何寫入操作，其邏輯取決於其他聚集（即用戶/帳戶設置）來驅動域邏輯 –
引用如何失效？如果你讀了一個很快就會改變的比率呢？如果這並不重要，那麼只需在域中聲明一個RateService接口，然後實現可以從任何地方獲取數據，則它變得無關緊要。 – plalx