為了提高系統吞吐率，也就是提高生產效率，核心觀點如下，系統設計也是如此 在微服務或任何其他基於事件的架構(event-driven-architecture)中，在一些用例中，一個服務可能需要我們對他們自己的本地資料庫進行修改，同時發佈一個事件。然後，該事件會被其他服務所消費。為了擁有一個一致的軟體 ...
單一職責原則
1.1 我是“牛”類，我可以擔任多職嗎
單一職責原則，英文名稱是Single Responsibility Principle，簡稱是SRP，定義是應該有且僅有一個原因引起類的變更。
什麼是類的職責，以及怎麼劃分類的職責？
舉例：rbac模型
這個介面設計的存在問題：用戶屬性和用戶行為沒有分開
把用戶信息抽取成一個BO（Business Object，業務對象），把行為抽取成一個Biz（Business Logic，業務邏輯），我們面向介面編程，所以產生的UserInfo對象可以當成IUserBO介面使用，也可以錄成IUserBiz介面使用
IUserInfo userInfo = new UserInfo();
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();
在實際使用中，我們更傾向於使用兩個不同的類或介面，如下：
1.2 絕殺技，打破你的傳統思維
舉例：電話設計
這麼設計的問題是IPhone介面不只有一個職責，分別為：一個是協議管理，一個是數據傳送。
這樣設計引起類間耦合過重、類的數量增加，人為地增加了設計的複雜性
這樣設計，一個類實現兩個介面，把兩個職責融合在一個類中。
單一職責原則的好處
實現什麼職責都有清晰明確的定義，這樣類的複雜性降低，可讀性提高，可維護性提高
1.3 我單純，所以我快樂
單一職責適用於介面、類，同時也適用於方法。
要修改用戶名稱，就調用changeUserName方法；要修改家庭地址，就調用changeHomeAddress方法；要修改單位電話，就調用changeOfficeTel方法。每個方法的職責非常清晰明確，不僅開發簡單，而且日後的維護也非常容易。
1.4 最佳實踐
大部分情況下類設計都是與單一職責相違背的，類的單一職責受到非常多因素的制約，現實你必須去考慮項目工期、成本、人員技術水平、硬體情況、網路情況甚至有時候還要考慮政府政策、壟斷協議等因素。
對於單一職責原則，建議是介面一定要做到單一職責，類的設計儘量做到只有一個原因引起變化。
參考：
- 《設計模式之禪》第2版
