領域知識與使用情境

最近很多人聊到這問題，記錄一些想法，這些想法我在很多領域都實踐過。

對於開發者而言，必須能夠了解全貌，看出最複雜的狀況是什麼，然後才能用 #領域知識與 #使用情境『簡化』給使用者。

什麼叫做最複雜的狀況？簡單的說法就是各種面向的情境，我常說的就是 X, Y, Z .... 各是什麼？裡面有哪一些因素需要被列舉出來？最後的排列組合是怎樣的組合？找到 X, Y, Z, ... (N個) ... 找到他們個別可以列舉哪一些因子，最後推演出最複雜的情境。

解決方案，需要能夠滿足最複雜的情境。

最近跟不少人聊到複雜跟簡單的問題，大多都希望要給使用者很簡單的使用體驗。但大多搞錯方向，以為自己也要很簡單。使用體驗 (UX, DX) 很簡單沒問題，但是對於整體結構的理解，不能很簡單的理解。

有人踩複雜的方式，就是找到最複雜的情境，然後寫個演算法去解決。我則習慣用 #集合、#時間與 #空間這三個慨念表達，所以很多人會以為我喜歡畫圖，不是，那只是我的工具與表達方式而已。同樣東西我也跟不同領域的人講過，他們也聽得懂。

簡化前，先搞清楚全貌，全貌勢必是複雜的。

常見問題與現象

為了簡化而簡化，還沒搞清楚狀況，就在簡化。

一鍵部署: 最常見的就是 CI / CD 的 pipeline，也就我最常說的 #一鍵部署。詳細說明與理由參閱這篇，不贅述。
AP 的配置檔 (Config)，他是整個 AP 的介面，介面隨著時間與架構調整，變多是必然的，至於是否複雜，就要看過程是否有做適度的『設計』。Config 的本質就是依賴注入 (DI)，目的則是依賴反轉 (IoC)，讓之後部署的人可以依照狀況做調整。他可以有最簡單的配置，與預設值。過度簡化的 Config 是沒有 Configurable，使用者必須能取得 Config 的資訊，然後能依此做適度的調整，而不是完全不讓使用者知道這些東。
產品功能的彈性設計。越有彈性的產品，底層會越複雜。中介層透過結構化配置滿足快速的業務需求。中介層是設計給開發者使用的，業務層看的則是簡單的介面，通常這些介面代表著業務邏輯。業務需求改變時，只要增減中介層的結構，就可以滿足業務層，不需要改程式碼。

常見的問題就是：想要從業務層完全簡化，卻沒有彈性的中介層結構。

這個案例最好的應用，就是 DSL (Domain-Specific Language)，使用對象是 Domain Expert。

... TBD.