如果我們考慮一個標準的持久性存儲庫，解決方案很簡單。我們將IStuffRepository放入域層，並將StuffRepositoryImplementation放入基礎設施層。DDD - 第三方API接口應該在哪裏？
但是，當我們想要包裝第三方API時，什麼是好模式？
我們可以應用相同的模式，在域層中有一個IStuffGateway，在基礎設施層中有一個StuffGatewayImplementation。
但是這種方法存在問題。當我們考慮持久層時，我們控制着我們堅持的數據。但是當我們考慮第三方API時，我們沒有任何控制權，這意味着我們可以嘗試擁有特定的接口簽名，但它必須受到我們正在包裝的內容的影響。所以如果我們改變實現（用另一個替換第三方），接口簽名可能會改變，並且域會被改變。
另一種方法是將接口移到域外，並將其放入Infrasture Layer中，並將其實施。這樣，應用層就可以毫無問題地使用它（並保持域不變）。但是這種方法從域中刪除了重要的概念，從我的角度來看這似乎很糟糕。
有關此參考的任何意見？
我總是保持我的Domain對象（Aggregates）純淨，沒有副作用。這意味着我沒有從Domain到任何其他層的任何依賴關係。持久性/存儲庫始終位於Infrastructure。 Application圖層使用它來堅持Aggregates。
當我使用CQRS時，我只保留我的寫/命令端（Aggregates）純。 Readmodels是依賴和優化的具體實現。最近我用了很多MongoDB來實現持久性。
當我不使用CQRS，我保持整個Aggregate沒有依賴關係（我沒有選擇，拆分將CQRS）。
所以，所有的情況下，Domain沒有做任何IO，它沒有副作用。這主要是因爲在併發更新的情況下，我需要能夠安全地重新執行Aggregate上的命令。
如果您決定使用接口，則應使用DIP：Domain擁有Interface;這意味着域名決定了方法的編號和簽名。
我想我沒有正確表達自己，因爲我從來不想暗示我的域作爲依賴關係到其他層。我所說的是我的存儲庫接口（IStuffRepository在我的域中聲明）實現（StuffRepository）在基礎設施層 問題在於接口的位置包裝了我對外部API的訪問 –
您確實表達了外部持久性不應該影響你的域模型，當外部持久性改變時，你的Repository接口應該具有相同的簽名（加載，保存，刪除），該接口的位置應該保留在 –
這對於數據倉庫來說是正確的，但是我的問題與持久性存儲庫沒有關係，接口封裝對第三方API的訪問並不是這種情況，想象一下支付網關，你需要提供一個clientId作爲Guid 。這個第三方問題直接泄漏到你的域名中，而你改變薪水的那一天nt提供者，也許你需要一個clientId作爲整數。這就讓我感到困惑，因爲域層應該是放置IPaymentGateway接口的適當位置，因爲它代表了有界上下文的用例。 –
我在這裏和康斯坦丁一致。
您可以仍然保持在您的域名的概念，但不是IO。應用程序層應提供所需的域對象。您可以打電話給您的反腐敗層（IStuffGateway），然後獲取您通過某個電話傳遞到您的域所需的對象。
如果這是一個常見任務，您可能需要引入一個包裝該位的應用程序服務（IGetStuffAndCallDomainTask）。
我的問題是關於封裝第三方API的接口的位置。通常，存儲庫接口位於域中，而實現位於基礎結構層中。但是當涉及封裝外部API的接口時，應用相同模式會有一些缺點，因爲缺少對簽名的控制。 –
由於它不是一個真正的域問題，所以不應該在那裏定義接口，不。也許你的ACL將是一個更合適的位置。 –
所以你說我的域名應該不知道關於外部API封裝的一些接口簽名？這意味着當編排一個完整的業務用例時，應用層將是唯一需要注意的地方（通過基礎架構層中的反腐敗層）......這樣做肯定會起作用，但我仍然覺得這個領域應該知道的東西。但確實調用外部API通常不涉及任何業務邏輯，並且是應用層中業務用例的一部分。 –
當第三方持久性發生變化時，您會做什麼？你去找股東並解釋他們的業務需要改變嗎？ –
當然不是。持久性是一個實現細節。但是第三方API提供者並不總是隻有實現細節。例如，如果一家企業將FedEx API包裝爲自動化部分運輸，那麼這是股東所關注的事情。如果由於某些商業原因他們切換了提供商，那麼以某種方式影響域名是正常的。即使有反腐敗層，與第三方API相關的一些關鍵概念（如確認編號，SKU等）可能會泄漏到域中。 –
看來你的域名確實取決於一些第三方API。在這種情況下，我不知道定義＆取決於'接口'是否有幫助，因爲細節很重要（並且接口刪除了一些細節）。 –