行爲驅動開發（BDD）如何與域驅動設計（DDD）協同工作

Question

我對BDD的理解是，在用戶故事中描述一個系統，然後開發人員將這些用戶故事轉化爲應用程序，真正的商業價值與每個'衝刺'（軟件開發階段）。結果（據我所知）是在整個開發過程中，域模型來自用戶故事。也就是說，在第一次「衝刺」之後，很多領域模型都不會被設計出來。

我對DDD的理解是，軟件開發將繼續參考完整領域模型，儘管這是一個不斷髮展的模型。在DDD中，模型預計會發生變化，但它始終是「完整的」。

這似乎是兩種方法之間的根本區別。人們如何處理這個問題？

Answer 1

BDD做得很好不是產生了一個「完整」的模​​型。有一個原因，丹BDD提出了他的博客"embracing uncertainty"。

我覺得現在有用的三種東西我們可以分析：已知的，可知的和不可知的。

已知的東西很簡單 - 例如，登錄。它很好理解。我們不需要談論這些情景。

可以知道的東西通常與域相關，或者與之前做過的事有關。這是做BDD的好地方，因爲它有助於將知識 - 包括領域模型 - 從企業轉移到開發人員。通過場景談話是更好地理解故事的好方法。它也可以幫助我們找到我們錯過的場景。 Chris Matts是幫助將「給定」放在「給定，當時，然後」稱爲「打破模型」的分析師。他實際上爲任何能夠想出他的模型中未涉及的場景的人提供獎勵，他使用場景來定義和優化。

還有一些不可知的東西。無論何時我們正在研究新的事物，或者我們以前從未做過的事情，或者沒有人擁有專業知識的事情，都會發生這種情況你可以告訴你是否在這個地方，因爲當你想出他們沒有想到的情景時，商界人士會開始反應。 BDD是找到這些地方的一個非常好的方式，但是在這一點上，您可能想要停止嘗試確定場景並嘗試一些東西並獲得反饋。您的域名模型，您的用戶故事以及您的場景都將逐漸顯現（see the complex domain in the Cynefin model）。

我知道很多團隊使用BDD作爲一種顯然消除這種不確定性的方式。你無法消除它。你只能隱藏它，直到以後，當交貨的反饋回來咬你。

對於DDD，當我們做到這一點與BDD我們往往把重點放在那些部分領域模型是相關的，我們正在處理的情況下，雖然我們可能有更大的域的想法整體模型。如果您將Feature Injection與BDD一起使用，則您已經討論了系統的大部分功能，尤其是新功能，因此您可以瞭解該域中是什麼類型的東西。進化和所有其他規則仍然適用。 BDD和DDD真的很好地結合在一起，圍繞場景進行對話，幫助推出領域語言。它們並沒有根本的不同，但完全支持和兼容。

請仔細閱讀the answer I gave to this similar question，其特點是單北和我談論這個題目的視頻。

Answer 2

我將包括用戶的故事，DDD和BDD因爲他們是非常非常依賴對方。我試着總結一下在這裏的鏈接：http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/

我希望這幅畫是既簡單又豐富，足以解釋在SlideShare上的幻燈片，這些「概念」