《微服務設計》閱讀筆記（十）康威定律和系統設計
《微服務設計》，Building Microservices，作者Sam Newman，譯者崔力強、張駿，人民郵電出版社，2016年。
筆記中有些內容直接引用原書。
================================================================
第十章 康威定律和系統設計
梅爾?康威於1968年4月在Datamation雜誌上發表的「How Do Committees Invent」文章指出：任何組織在設計一套系統（廣義概念上的系統）時，所交付的設計方案在結構上都與該組織的溝通結構保持一致。
1. 證據
松耦合組織和緊耦合組織。緊耦合組織的代表是商業產品公司，松耦合的代表是分散式開源社區。研究發現組織耦合度越低，其創建的系統的模塊化約好，耦合也越低。反之亦然。
Windows Vista。對該產品的研究表明：與組織結構相關聯的指標和軟體質量的相關度最高。
2. Netflix和Amazon
二者都是崇尚小團隊開發。
3. 我們可以做什麼
看看不同組織的情況。
4. 適應溝通途徑
5. 服務所有權
服務所有權：擁有服務的團隊負責對該服務進行更改。延伸開來包括需求、構建、部署和運維。
6. 共享服務的原因
共享服務所有權效果不佳，採用共享服務的原因如下。
難以分割。拆分成本高。可參考第五章的建議。
特性團隊。基於特性開發的團隊。例如一個團隊專門負責用戶界面，另一個負責應用邏輯，另一個負責處理資料庫。這還是服務共享，會出現大量問題。服務應根據業務建模，而不是根據技術。
交付瓶頸。共享服務，可以避免交付瓶頸。因為人員可以共享。但可以使用下面的方式避免採用共享服務。
7. 內部開源
核心提交者是代碼的守護者和代碼庫的所有者，其他人要修改代碼，向他們提交pull，核心提交者來審核。
守護者的角色。好的守護者會花大量精力與提交者進行清晰的溝通。
成熟。代碼成熟後再允許外部提交者貢獻代碼。
工具。支持pull的分散式版本控制工具，支持討論和修改提交申請的工具等。
8. 限界上下文和團隊結構
根據限界上下文確定服務邊界，與團隊結構保持一致。
9. 孤兒服務
不再活躍維護的服務仍然有其所有並負責的團隊。
10. 案例研究：RealEstate.com.au
每條業務線有其團隊，負責自己創造的服務的整個生命周期。一個核心服務交付團隊，為這些團隊提供建議、指導和工具。一個業務線內的服務可以不受限制的通信，業務線之間的服務通信必須是非同步批處理。
11. 反向的康威定律。
無論系統有什麼設計缺陷，都不得不通過改變組織結構來推動系統的更改。
12. 人
從單塊系統開發人員過渡到微服務系統開發人員需要時間來適應和改變，給他們時間，告訴他們的職責。
13. 小結
要盡量使得系統設計與組織結構相匹配。
BrianZhang：《微服務設計》閱讀筆記(一)微服務
BrianZhang：《微服務設計》閱讀筆記（二）演化式架構師BrianZhang：《微服務設計》閱讀筆記(三)如何建模服務BrianZhang：《微服務設計》閱讀筆記（四）集成BrianZhang：《微服務設計》閱讀筆記（五）分解單塊系統BrianZhang：《微服務設計》閱讀筆記（六）部署BrianZhang：《微服務設計》閱讀筆記（七）測試BrianZhang：《微服務設計》閱讀筆記（八） 監控BrianZhang：《微服務設計》閱讀筆記（九）安全BrianZhang：《微服務設計》閱讀筆記（十一）規模化微服務BrianZhang：《微服務設計》閱讀筆記（十二完結篇）總結軟體開發之路
推薦閱讀：
※如何應對線上故障
※《Cloud Native Go》筆記（一）雲之道
※《微服務設計》閱讀筆記（十一）規模化微服務
※《Cloud Native Go》筆記（十五）結論
※《微服務設計》閱讀筆記（六）部署