文章同步於blog

前言

終於來到Clean Architecture的最後一天了，這本書要全部講完基本上一個鐵人賽可能就不見了
我後面還需要留篇幅講解其他的部分，所以容我只分享Clean Architecture的一部分內容
這本書真心推薦大家擁有一本，不論是你在做自有產品還是接案公司

最後我們來講講書中的會尖叫的架構
順便分享一下我實際的案例還有我過去實作的經驗

架構的目的

良好的架構會以UseCase為中心，也就是說要圍繞著使用者要做的事情為中心開始打造一個我們所需要的架構。
例如說我今天要做的是一個店商網站的客戶行為分析系統，那我們就會從這個主軸來做設計，設計我們要的資料庫、資料庫欄位、所需要的程式語言、框架、API格式等等。

一個好的架構是讓專案可以到後期都可以不需要去決定我要的框架(Rails, Django, Laravel...)、資料庫等等，也就是說他保有彈性的空間，且可以讓別人一看就知道這是在做甚麼

真實案例

在我還是個小菜逼時，我就曾經遇過架構和程式碼沒有彈性所造成的問題。
當時公司有使用A和B兩種資料庫，而我們的框架當時對於B資料庫是不太支援的

有一天我們接到一個問題說，某筆資料存不進去
於是我就開始找問題到底在哪
大概用了半天的時間，我還是找不到問題到底在哪，明明都可以運作，為什麼就是存不進去

直到我靈機一動想到，我們還有 B 資料庫
於是我又把環境改成B資料庫
結果發現，*，這個資料庫存Null的方式還有Boolean的方式怎麼那麼牛掰(ORM的關係)

最終就導致我們的程式碼必須在額外判斷資料庫是哪一個才可以存進去(當年的作法，不要噴我QQ)

事後再來思考，我認為有幾個問題

• 我們沒有審慎的決定要用什麼樣的框架
• 沒有單元測式
• B資料庫其實很特別，所以比較麻煩(應該知道我在說哪個了...
• 沒有留意到B資料庫在這個架構下，支援度比較低

參考資料

Clean Architecture(ch.21)