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

解決了Impact Map的問題，下一步就是思考如何將DDD的戰略思考與BDD的戰術實現結合起來，引導整個開發的方向。這一切當然地需要用實踐來解決，在前進中才能解決遇到的問題，所以暫且只得到以下的一個思路。

DDD+BDD的開發流程：

1. 項目伊始，使用Impact Map勾勒出系統的功能輪廓。
2. 找出Key Example，編寫相應的Specification及Feature文本。
3. 對領域進行劃分，將Specification劃入不同子域。
4. 統一Specification中的概念，建立特定子域內的通用語言。
5. 結合Specification的描述和子域的劃分，定義最初的BC結構。
6. 選擇核心BC，利用SpecFlow+NUnit等工具，用代碼實現Specification描述的Feature。
7. 通過捕捉Feature描述中的Given-When-Then，得到領域事件列表。
8. 逐個BC重復第6、7兩步，得到領域模型的原型。
9. 不斷審視和完善Specification，中間可能夾雜著BC的調整，使領域模型不斷演進和豐滿。
10. 利用SpecLog等工具生成領域模型的Living Documentation。
11. 通過自動化測試，審視業務流程是否達到預期。
12. 從領域模型由內而外，編寫應用接口層、UI層和基礎設施層的Specification。
13. 使用BDD工具，實現這些外圍Specification的自動化測試和文檔生成。
14. 經過若干次迭代，所有核心和外圍Specification都得到完美實現。
15. 系統通過集成測試和試運行，順利交付并完成歸檔。

對這個流程中，有幾點需要說明：

• 第3、第5步，對子域的劃分和BC的切分是難點，因為兩者并不一定是一一對應的關系。只是因為Specification的出現，可以讓我們用更具體的示例來進行這種劃分，而不是憑空地臆想。
• 第6、第7步，在實現Specification的自動化測試時，應高度關注各種領域事件及其觸發的結果，還要從saga的角度去思考這些事件之間的協調配合。這在CQRS Journey一書中有相應的例子可作參考。
• 第6、第7、第8步，在編碼的同時配合不斷完善的UML類圖和順序圖，應該能更好地反映系統全貌，或者幫助我們發現遺漏。
• 第12、第13步，UI的自動化測試一直是難點，也是我的弱項。盡管Specification by Example中有對UI自動化測試的專門闡述，但仍需要實踐才能真正變成自己的東西。
• 在任何時候，專注核心域都是要放在第一位的。包括Specification的編寫和Example的選擇，都要以此為原則，才能避免陷入實現細節的泥沼。

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

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