翻譯自：Behaviour-Driven Development Combined with Domain-Driven Design
行爲驅動開發（behavior Driven Development，BDD）在很大程度上是關於對話和示例的，但BDD的另一部分，即軟件設計部分，Konstantin Kudryashov在研究如何將BDD與領域驅動設計（Domain Driven design，DDD）結合起來，將轉換位與以領域爲中心的設計活動結合起來時解釋了這一點。
Kudryashov，作爲BDD實踐經理，描述了BDD中使用的兩種用戶故事編寫場景樣式；一種命令式樣式，從技術角度描述了應用程序的工作方式，通常與實現相結合；另一種是聲明式樣式，他更喜歡這種樣式，描述問題和用戶想要實現的目標。無論使用何種風格，大多數BDD實踐者都會停留在這個層次，使用這些場景來驅動實現，但Kudryashov認爲這還不夠，還缺少很多對業務很重要的細節。通過與領域專家交談，澄清命名、尋找缺失的關係等，場景可以寫得更詳細，當用業務人員和開發人員共享的通用語言編寫時，將出現一種無處不在的語言，這是DDD中的一個關鍵概念。通過這樣編寫場景，Kudryashov聲稱場景可以成爲領域模型。
努力推動通用語言使你的例子成爲一個領域模型。
對於大多數BDD從業者來說，方法是通過用戶界面UI測試每一個場景，在外部進行測試。相反，DDD實踐者最關心的是領域核心，對他們來說，領域核心隱藏在一個緩慢而脆弱的UI後面，因此他們傾向於從域核心開始，直到核心的實現足夠穩定，纔在核心之上實現UI。
強調一點，Kudryashov引用了沃恩·弗農（Vaughn Vernon）在其著作《實現領域驅動設計》（Implementing Domain Driven Design）中的話：
應用程序邊界或內部六邊形也是用例（或用戶故事）邊界。換句話說，我們應該基於應用程序功能需求創建用例，而不是基於不同客戶端或輸出機制的數量
爲了將BDD和DDD實踐結合起來，需要將這兩種技術結合起來，Kudryashov首先刪除UI，然後在領域中運行測試。從領域開始，與業務人員的對話就變成了架構師；根據用於描述問題域的詞彙，不同的架構自然地出現在領域中。Kudryashov發現這樣做的一個優點是，在顯示工作場景之前，消除了持久性和UI的需求，在與領域專家的對話中，反饋循環大大縮短，從而大大加快了對領域的理解。
使用這種方法，UI不再是應用程序的中心，而只是領域的控制器。當用戶界面被添加時，只有對用戶界面至關重要的場景和應用程序是必需的，因爲域已經被證明可以工作。
在去年的一次演講中，伊恩庫珀談到了使用六邊形架構時的行爲測試。