转载

談軟體設計：尊重每一個使用者 - 依賴反轉

一段埋藏在心裡很久的設計想法，有天在公車上把他敲下來，主要是 IoC (Inversion of Control) 的設計概念。

很多年前第一次看到 AWS IAM 的 Policy，第一時間想得到就是權限管制與政策的設計就是這樣。

很久以前設計權限系統，大多以 AOP 概念設計，但是那僅只於功能上的實踐方法，透過 AOP 的關注點分離，讓商業邏輯與授權邏輯更加拆分，但並沒有考慮企業用戶實際上在使用時，如何有個方法可以設計自己的『授權邏輯』，然後定義屬於自己的授權政策。

後來跟同事無意聊天中，把這個設計概念抄過來，也就是授權邏輯程式碼的想法 (Policy as Code） 。企業用戶要的是高度彈性與高度客製，要設計可以滿足客戶的業務功能，其核心概念就是『依賴反轉』，或者『反轉依賴』。

『依賴反轉』的概念就是：

你要什麼，我讓你自己決定。

用程式碼系統概念來說：

SDK / CLI 這些東西就是依賴反轉的最佳範例

他把所有的參數都寫在文件裡，讓使用者自行決定如合透過參數達到自己想要的功能。這種概念這幾年發揮到極致的 宣告事設計 (Declarative) （K8s deployment yaml，Terraform 都是），透過這種『反轉』的概念讓客戶決定自己要什麼，可以設計屬於自己的政策。

AWS IAM Policy 的設計概念也是一樣，這樣的概念能滿足企業用戶必須要的彈性與複雜度。另一個類似的概念就是 Redmine 的 Filter 設計，其核心概念已是依賴反轉。使用者只要能夠定義出來想要看什麼，只要能夠指定條件，就能設計各種面向的查詢與視角。

『依賴反轉』的設計看似好，但實際上它也依賴於使用者自身的能力，換言之，使用者對於自己的『需求』要有一定程度的自知之明。這概念如同 Unix / Linux 的概念一樣：

尊重每一個使用者，假設你知道自己要什麼樣。

『依賴反轉』提供高度客製化與彈性機制給使用者，而『反轉依賴』則提供最佳實踐給使用者，也就是很多人想要找的 best practice。這場種概念實際上就說是某種『專家系統』。以前我常舉的例子就是微軟的 Powerpoint，他的設計從一開使只有提供一堆功能，到後來提供了很多常用的樣板，甚至是很專業，且是針對性的『主題』，例如針對行銷的樣板，針對產品發表會的。。。等，而一些行銷公司也提供了更專業的樣板販售，這背後販售的是『經驗』。

產品的設計，初期都會是單一個功能，然後是功能的集合，最後是把實踐放入，但是依照不同的使用對象，會提供不同的視角與產品線。頻果的音樂製作產品 GrageBand 和 Logic Pro 究竟是兩個差異化的產品。

你在開發產品，但也在用別人的產品，你感覺的到他們的差異？

— 未完 (公車開太快，到公司了)

原文 https://rickhw.github.io/2019/09/12/Architecture/Design-with-IoC/

正文到此结束