前言

昨天的文章我們講到了Request Driven的特性讓維護與開發人員掉髮的原因之一。

今天我們繼續講其他幾個掉髮的原因，湊齊掉髮三件套((淚留滿面。

好了～我們開始吧!!

Request Driven的挑戰

昨天的文章我們說過一個create folder的api實際上會做以下幾件事情:

1. validate: 系統驗證request body是否符合系統要求的規格
2. get folder: call get folder的service確認parent id的資料夾(父資料夾)是否存在
3. query folders: call query的service確認父資料夾底下的所有資料夾名稱有沒有跟使用者想建的重名
4. create folder: 在db裡建立這裡資料並回傳給瀏覽器

當所有的操作完成後，文件才成功被建立在db，其中一項操作失敗都會導致請求失敗。
除此之外，還有其他兩個問題:

1. 包含太多邏輯: service中如果包含過多的邏輯就會增加出錯的可能性，還會讓開發人員寫測試的時候要確保"相依"的程式/service沒有問題，否則測也是白測。
   ex. 開發人員要寫create folder的整合測試，必須先確保get folder和query folders這兩支程式的邏輯正確無誤。其中一個邏輯有問題或結構更動，會造成create folder的邏輯跟測試出錯。
2. I/O風險：service相依的程式會不斷地跟db要資料，這大大增加I/O出錯的風險。

這還是簡單的create folder的api，當系統的複雜度提升，規模越龐大時，api與api、api與service、service與service...之間的相依性會越來越可怕，測試變的非常難測，可能一個測試就要寫將近千行的程式，可讀性可想而知。

總結

因此，Request Driven的這些問題非常值得工程師們與團隊思考，特別是如何設計才能讓測試變的好測試，程式之間的相依性不會那麼高。
接下來會進入Event Driven的世界，嘗試用不同的方法解決這些問題。

好了～～今天就到這邊!!