提煉事實

義大利麵條事實
這是DDD的重點，避免混合各種“事實”。
理解企業的“事實”需要大量的時間和分析。這是一個迭代的任務。領域專家分享“事實”，因為他們共享一些業務流程。例如，營銷團隊的某個人會從另一位同事那裡瞭解營銷，但她並不總是瞭解來自貨運團隊的同事。他們面臨著不同的挑戰，他們使用不同的語言：他們在不同的“事實”中工作。

來自DDD的戰略模式幫助我們構建特定於上下文的解決方案，以便構建僅匹配一個“事實”的軟體，從而避免透過共享抽象一個共同“事實”，因為後者是將“事實”誤以為真理，在這個追尋所謂真理過程中卻獲得了難以管理的複雜程度。

如何選擇事實
必要的複雜性是解決方案的最純粹形式，意外的偶然的複雜性是指我們開發的解決方案比問題所要求的更復雜。

在Ben Moseley和Peter Marks的優秀的論文中，他們解釋了我們是如何在軟體中帶來技術偶然的複雜性，特別是在狀態控制（事情發生的順序）和程式碼體積（程式碼的行數）。

我認為我們經常錯過了尋找領域中偶然的複雜性的機會。我們認為問題已經很好理解，而大部分時間卻都有改進的餘地。

如何實現“事實”
如果我們同意“事實”的概念是指所有先前事實的結果，那麼尋找表示這些事實的實施是有意義的。
這樣的實現將更容易轉化為事實，反之亦然。這樣的實現有助於描述軟體的本質：它是一個基於過去事實的自動決策者。

這種實施已經成為“事實”概念
使用者向軟體傳送一個願望（“我想這樣做......）”，軟體根據自己的現實（即它知道的事實）作出決定，並將反饋資料傳送給使用者以幫助她找到她的下一個願望。
只需用事件替換世界“事實”概念，用命令實現意願，透過使用者反饋查詢以查詢這些概念的現有實現。