我經常讀到，如果團隊無法訪問域專家，則不應該執行DDD。 但是，如果域名不是微不足道的，但DDD有什麼替代方案，但沒有域專家可用，並且該團隊只能訪問代理域專家或僅訪問產品所有者。我可以在沒有領域專家的情況下進行領域驅動設計嗎？
在這種情況下，團隊不應該創建一個共同的語言，在有限的上下文中創建一個領域模型，使用聚集和聚合根來強制執行業務約束，使用存儲庫來確保模型的持久性無知等。
我知道DDD不是一個完整的或沒有的東西，它沒有描述一個架構 ，而是一個設計方法。但是，如果僅僅因爲領域專家不可用而在複雜的領域中使用DDD的戰術模式和策略設計，那麼這難道不會讓人感覺到嗎？當沒有領域專家可用時，我不會使用哪一部分DDD？
什麼你實際上需要的是一個領域的專家作爲作用，不一定作爲具體的物理人（不是一個或多個開發團隊成員（們）等）。擁有「真正的」領域專家是可取的，但並非總是可行。在這種情況下，開發團隊必須積累專家領域知識 - 我知道這並不完美，但完全可能（在實踐中並不罕見）。
第一個，我沒有讀過你不應該在團隊沒有訪問領域專家時執行DDD。
域模型和域驅動設計的主要優點是使用Ubiquitous Language。它是「開發人員和用戶之間通用的，嚴格的語言」。
它被用來解決開發商和企業之間的誤解。
當一個項目的語言斷裂時，項目會面臨嚴重的問題。領域專家使用他們的專業術語，而技術團隊成員有自己的語言進行調整，以便在設計方面討論領域。日常討論的術語與代碼中嵌入的術語（最終是軟件項目的最重要產品）是分開的。甚至同一個人在講話和寫作使用不同的語言，...
，要麼開發團隊或企業客戶應該使用相同的詞彙工作的一個項目。
使用該模型作爲語言的支柱。承諾團隊在團隊內部和代碼中的所有溝通中不懈地運用該語言。在圖表，寫作，尤其是語音中使用相同的語言。
認識到語言的變化是對模型的改變。
在你的情況下，足有「訪問代理領域專家或只對產品負責人」。
在Scrum過程Product Owner (PO) is a bridge between development team and stakeholders。
當開發團隊執行業務使用Ubiquitous Language，開展業務分析的開發人員和業務人員/ PO一起形成該語言時，這很常見。
有時業務對於單個「實體」，「過程」或「功能」有幾個術語，選擇正確的一個術語是一項挑戰。
二，既然是球隊的責任作出架構決策和設計應用程序，他們可以"create a common language across the team, create a domain model within bounded contexts, use aggregates and aggregate roots to enforce business constraints, use repositories to ensure persistence ignorance for the model, etc"當它是合理的。
第三，我認爲做或不做DDD的決定取決於軟件的要求，並不取決於域專家的可用性。
很好的問題 – Coldstar