剛開始使用DDD。我知道所有的域實體及其邏輯都應該保存在域層以及存儲庫接口中。在我的應用程序中，我將一些數據存儲在數據庫中，用於在運行時構建用戶界面（表示層）的一部分。在應用層或域層中，我應該在哪裏爲這些類型保留poco類和存儲庫接口。我無法做出決定，因爲這些對象不會有任何域相關的業務邏輯，但他們需要從數據庫中獲取水分，因此我使用EF來訪問數據，因此我需要實體和存儲庫，所以對我來說顯而易見的選擇是讓它們與域層中的所有其他實體和存儲庫接口，但會打破DDD規則DDD中的非業務邏輯數據庫訪問
想到這一點的一個好方法是 - 如果您出於性能原因必須用存儲過程替換EF，則不應該修改域代碼。因此，任何需要在接口背後隱藏的東西都是可以替換的。
存儲庫可以是域邏輯的一部分。但是，不應該持久化的機制。這可以輕鬆地封裝到DAL服務或其他對象中，當然這些對象被編程爲IDALService接口。因此，當您需要切換持久性時（例如，從EF移動到NoSQL解決方案），您只需編寫一個實現IDALService接口的替代版本，那麼您就很好。存儲庫仍然可以執行其中的邏輯，但現在正在使用一種新的方式來存儲它們（這是一個控制反轉的想法）。
至於POCO對象，在DDD中真正的問題是它們代表什麼？他們是實體，需要堅持嗎？他們是否重視對象？不要讓技術（EF）確定您的對象模型的結構，而是提供轉換爲應用程序範圍的手段。
在應用程序層。保持域完整和孤立。
我想你已經回答了自己的問題：
在我的應用程序在數據庫中存儲一些數據，在運行 用於用戶界面的 結構部分（表示層）時間。
訪問用於服務UI的數據應封裝在表示層中。這與應用程序層的不同之處在於，DDD應用程序層通過編排存儲庫並委託給相應的實體和域服務來實現用例 - 它在您的域層周圍形成一個API。不同的演示實現可以使用相同的應用程序服務
但是，不同的表示層實現可能需要不同的數據。因此，將表示數據訪問直接放置在表示層中。這可以通過EF來實現，而不是DDD場景所獨有的。