從語言之爭到框架之爭
最近或應該說時常看到網路上有人提到：新出來的xx 語言海放了 oo語言，不意外的就會有人開始贊(ㄍㄠ)同(ㄔㄠˊ)，然後就有人會出來為oo語言辯護，但事實上xx語言的擁戴者並沒有看到oo語言背後的生態與多年以來發展的工具、框架等，那才是這個使用多年oo語言的價值所在。另外，要說的是Spring Framework發展多年來，也搭上雲原生的熱潮，推出了易於開發微服務的 Spring Boo與 Spring Cloud；而另一支號稱真正基於雲原生需求的開發框架 Quarkus，也開始蓬勃發展且來勢洶洶。但是，其實我更關心的是我怎麼解決手上的問題，完成任務，讓團隊可以平安的回(ㄊㄨㄛ)家(ㄕㄣ)，所以，更想知道如何正確且有效率的滿足不斷改變的需求。也許，我們還真的聽聽某電信公司的廣告詞：世界變化越快，而我們的心則要越靜(OS：明明就是你們自己的網路太慢，要大家等XD)。
回顧過去
過去大家開發一個系統，多半會先談好這是一個Web或是Mobile的應用、要用某框架、會用某種資料庫、有做到MVC pattern，系統設計則是很簡單的將系統橫切面分成 Presentation/Business Rules/Data Access，再將每一個功能模組由上而下的實作，看起來挺有規劃的。每個Developer都忙著追趕SA彈回來的規格，忙著寫bug與改bug。客戶在專案開始的時候，多半也會親切的同意Developer自由發揮，但是當第一版畫面出現的時候，就是系統開始要改變的開始。更別說過程中，Developer B想建一個資料表，被客戶或是架構師否決，然後被指派去跟Develop A共用一個資料表，然後就開始展開糾纏且糾結的人生。等等，那建模呢？不就是看客戶想要畫面上要輸入什麼？跟以後報表要長成什麼樣子，拉一拉 Class 與 Table就好。哈。
展望未來
Clean Architectre 是Clean Code 系列書籍的其中一本，由鼎鼎大名的Uncle Bob所編寫。Clean Architecture的名稱翻譯落落長，我們就簡稱為”簡潔架構”吧。簡潔架構提到幾個重點，其中分層概念顛覆了我個人對於系統分析與開發的順序；參考圖如下，來源
由內而外來解讀
Entities：為解決Problem Domain建模後的結果。
Use Cases：可視為該系統所呈現的行為，或可以說是Business Rules。
Controller/Gateways/Presenters：則是隔離了最外層，也就是傳統的IO層。
UI/Web/Devices/DB/External Interface：一般來說，不一定是我們程式碼的一部分，而是該系統與外界交互作用的統稱。
簡潔架構特別強調分層解耦，即使要有耦合，也要讓負責對外IO的低層相依於Domain Model的高層。試回想，過去的三層式規劃，最上面的Presentation與最下面的 Data Access，皆是簡潔架構中的低層IO。如果沒有解耦，Domain Model可能就會遷就某一種對外的IO，而發展出專屬某種IO的系統架構。書中提到了SOLID原則，反向相依提供了解耦合的建議實作方式，非常具有參考價值。SOLID原則，我們以後再談。
順便談一下框架；Spring Framework 著實地影響了Java Developer數十年，因此在專案開發中，常常是整個系統架構的主幹，這無所謂對錯問題，但會讓系統設計迷失關注的焦點，誤把Spring 甚至任何框架當作主軸來開發，這對系統長遠的發展並沒有幫助，甚至未來還有可能要配合框架的發展，而調整系統，完全失去當時建模的初衷；也變成與框架的耦合，讓Domain Model 不夠簡潔。
永恆之道
熱力學提到熵增原理用來描述一個系統發展的命運，簡單來說：一個系統只會越來越混亂。現在看來，不管是地球還是我們開發的系統，還真的符合了熵增原理的預測。但是，我還是期待可以為手上進行的專案找到永恆之道，也幫大家找到順利且快速回家的道路。設計思維與方法論，似乎是目前最有可能的答案。
