為什麼我推薦功能驅動的軟體設計方法？ - khalilstemmler

偶然的複雜性
在大多數主流程式語言中，都存在狀態和序列的概念。根據本·莫斯利（Ben Moseley）的說法，狀態和序列是 意外複雜性的兩個主要原因：

• 狀態：“您是否嘗試過將其關閉然後再次開啟？” 以前有沒有人對你這麼說過？當系統最終處於非法狀態時，就會發生這種情況。維持狀態很難。我們必須跟蹤變數，例項等。
• 順序：首先，我們執行這個操作，然後才需要執行那個操作，但前提是發生這種情況”。我們大多數人都使用支援過程和條件的語言編寫。當我們必須確保事物按特定順序發生時，我們還將引入表面積，這樣就提高了複雜性。

透過函數語言程式設計減輕意外的複雜性
這是（純粹地）函數語言程式設計的亮點。Scott Wlaschin的《領域建模的功能》一書描述了一種透過使用最少的狀態或序列來對功能/用例（他稱為工作流）進行建模來儘可能接近基本複雜性的方法。

這是一種非常徹底的方法。我認為這太神奇了。但是，真正的純鐵上下的函數語言程式設計是不適合心臟虛弱。這是一些嚴格的程式設計。透過從頭開始對整個域建模，類似於我們從第一原理建立數學方程式的方法，這確實是使非法狀態無法表示的方法。
 

結構與開發人員的經驗-FP很難
在軟體設計中，需要在結構Structure和程式設計師經驗之間平衡。90年代的OOP員工發現了一種很棒的功能優先方式，可以始終如一，可靠且自信地編寫包含狀態和序列的程式碼。
  

使用功能優先的TDD馴服（狀態和序列）複雜性
測試驅動開發不僅僅是對React元件和類進行單元測試。
透過找出一種繼續新增和更改程式碼的方式，並確保我們應用程式的功能仍然有效，可以獲得最佳的投資回報。這就是我們大多數努力的地方-因為這些功能畢竟是必不可少的複雜性。
執行TDD的“功能優先”方法是執行Double Loop TDD。
 

功能優先的集合
我發現的一些最佳技術可以幫助我們與當前問題的本質保持一致，並消除噪音（技術堆疊，語言，範例等），這些技巧如下：

• 事件風暴
• 事件建模
• 用例驅動設計
• 驗收測試驅動開發（也稱為雙迴圈TDD）
• ...還有更多，待續

  
您可以在前端和後端體系結構上以功能驅動的方式工作。看看DDDForum的程式碼，DDDForum是我們在solidbook.io中構建的應用程式。後端遵循按用例組織的功能優先專案結構。