1. TDD

TDD指的是Test Drive Development，很明顯的意思是測試驅動開發，也就是說我們可以從測試的角度來檢驗整個專案。大概的流程是先針對每個功能點抽象出介面程式碼，然後編寫單元測試程式碼，接下來實現介面，執行單元測試程式碼，迴圈此過程，直到整個單元測試都通過。這一點和敏捷開發有類似之處。

TDD的好處自然不用多說，它能讓你減少程式邏輯方面的錯誤，儘可能的減少專案中的bug，開始接觸程式設計的時候我們大都有過這樣的體驗，可能你覺得完成得很完美，自我感覺良好，但是實際測試或者應用的時候才發現裡面可能存在一堆bug，或者存在設計問題，或者更嚴重的邏輯問題，而TDD正好可以幫助我們儘量減少類似事件的發生。而且現在大行其道的一些模式對TDD的支援都非常不錯，比如MVC和MVP等。

但是並不是所有的專案都適合TDD這種模式的，我覺得必須具備以下幾個條件。

首先，專案的需求必須足夠清晰，而且程式設計師對整個需求有足夠的瞭解，如果這個條件不滿足，那麼執行的過程中難免失控。當然，要達到這個目標也是需要做一定功課的，這要求我們前期的需求分析以及HLD和LLD都要做得足夠的細緻和完善。

其次，取決於專案的複雜度和依賴性，對於一個業務模型及其複雜、內部模組之間的相互依賴性非常強的專案，採用TDD反而會得不嘗失，這會導致程式設計師在拆分介面和寫測試程式碼的時候工作量非常大。另外，由於模組之間的依賴性太強，我們在寫測試程式碼的時候可能不採取一些橋接模式來實現，這樣勢必加大了程式設計師的工作量。

 2. BDD

BDD指的是Behavior Drive Development，也就是行為驅動開發。這裡的B並非指的是Business，實際上BDD可以看作是對TDD的一種補充，當然你也可以把它看作TDD的一個分支。因為在TDD中，我們並不能完全保證根據設計所編寫的測試就是使用者所期望的功能。BDD將這一部分簡單和自然化，用自然語言來描述，讓開發、測試、BA以及客戶都能在這個基礎上達成一致。因為測試優先的概念並不是每個人都能接受的，可能有人覺得系統太複雜而難以測試，有人認為不存在的東西無法測試。所以，我們在這裡試圖轉換一種觀念，那便是考慮它的行為，也就是說它應該如何執行，然後抽象出能達成共識的規範。如果你用過JBehave之類的BDD框架，你將會更好的理解其中具體的流程。這裡我推薦一篇具體闡述的文章。

 3. DDD

DDD指的是Domain Drive Design，也就是領域驅動開發。這是一種非常好的思想，在我們剛開始學習程式，甚至剛開始學習三層架構的時候，我們曾經面臨過很多疑惑，比如如何來實現我們的資料層？後來我們開始學習MVC，MVP等架構，如何設計Model層又成了我們的新問題。我們見過太多這種情況，Model變成了單純的資料容器，也就是我們經常說的貧血模式。DDD實際上也是建立在這個基礎之上，因為它關注的是Service層的設計，著重於業務的實現，因此不可避免的以貧血模式為基礎而存在。但是它最大的特別是將分析和設計結合起來，不再使他們處於分裂的狀態，這對於我們正確完整的實現客戶的需求，以及建立一個具有業務伸縮性的模型，是有很大幫助的。