對結合BDD進行DDD開發的一點思考和整理

引言

二十年前的我，還在學校里抱著一臺DIY機（德州486+大眾主板+16M內存+3.5inch軟驅+昆騰320M硬盤，當時全校最快主機沒有之一），揣著一本《Undocumented DOS》，沉迷在Pascal、C以及匯編混合編程的世界里無法自拔。二十年后，軟件開發已遠不是當初幾張簡單流程圖可比，軟件開發的方向由簡至繁，各式的開發工具更是層出不窮，不僅讓新出道的人們深感亂花漸欲迷人眼，也讓我等備感跋涉之不易。所幸愛好不外有二，讀書實中其一。也唯有不斷學習，才不至被拍死在沙灘之上。

學習BDD，實屬偶然。在學習ES+CQRS的過程中，我認識到必須要轉變觀念，把傳統單一結構的領域模型一分為二，將其中反映系統狀態發生變化的部分封裝在寫模型里，而將查詢或呈現的部分封裝在讀模型里，分別設計、分別實現，再以領域事件為紐帶，實現整個業務的最終一致性。因此，發掘領域事件、理解最終一致性成為個中的關鍵。因此，我開始尋求發掘領域事件的方法學支撐。

在搜索引擎幫助下，我很快找到了一些社區和Blog上關于發現和挖掘領域事件的文章，而它們的觀點最終都歸結為了一點： 講好故事 。講好了故事，才能清楚我們究竟要什么，才能幫助我們劃清邊界，才能發現邊界間的聯結關鍵。于是，很自然地，BDD進入了我的視野，然后是Specification by Example，繼而是Impact Map。它們都可以幫助我們把故事講好。

這一篇，先總結一下這段時間的學習成果。之后再爭取學以致用，用一個具體的項目進行DDD+BDD的綜合實踐。

回首過往

既然是要在原有開發方法里摻入新的東西，那就說明現有方法必定有其缺陷，需要加以完善和改進。所以，先說說我們在此之前是怎么做DDD的。

• 剛開始，我們會有一個很原始、很初級的需求說明，大致說明項目的背景和主要需求。而這樣的需求不外有二，或是改進現有業務流程，或發現新的價值增長點。接下來，是若干次的見面會，通過討論和溝通，從客戶處得到的用戶故事越來越詳盡，業務流程因此得到逐步細化，一些關鍵的概念也得以逐步澄清。于是，用文本描述的角色、用例以及領域概念成為這一階段的主要產品。
• 然后，大家開始討論如何為整個系統劃定核心域和各子域，并嘗試用UML類圖和順序圖建立系統的模型、切分BC。最后，我們開始嘗試用TDD實現系統原型，并借由一些簡單的測試腳本，通過命令行窗口模擬系統的行為，幫助客戶更好地進行反饋。在此之后，由獲取反饋-改進模型-重構實現構成的每個迭代小節，成為我們的主要工作，也使得系統逐漸豐滿和完整。

  原文轉自：http://www.cnblogs.com/Abbey/p/5143674.html

  • 共7頁:
  • 上一頁
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 下一頁