敏捷微服務構建

王威： TW咨詢師、架構轉型教練、敏捷技術教練

敏捷的目標

敏捷的目標是提升效率？降低成本？減員增效？

敏捷：關注價值、快速反饋、快速響應。其的目標是提升響應力，響應力的提升不一定會提升效率、降低成本、減員增效
敏捷追求的是加速度，而不是速度（個人理解）。短期來看加速度不能提升速度，甚至會降低速度，但長期來看加速度可以提升速度！

敏捷的軟件架構

敏捷的軟件架構需要支持關注價值、快速反饋、快速響應。如何體現軟件架構的響應力（或加速度）？相對單體、分層的架構來說，微服務具有獨特的優勢：高內聚低耦合、獨立開發、獨立運維、高可測試性、延遲決策….

• 大泥團
  Product類承擔了過多的職責：產品價格的職責、產品運輸的職責、產品購買的職責、產品的個人化信息等等。各種職責的代碼相互糾纏，形成一個大泥團。
  
• DDD（領域驅動設計）與界限上下文
  從業務領域角度抽象界限上下文，對于產品分離出不同界限上下文的領域概念：市場領域的產品概念、銷售領域的產品概念等等。
  
• 領域架構
  將業務領域映射到一個獨立的微服務中，由單個微服務承擔此領域的產品職責。
  

關鍵問題

如何識別界限上下文？王威老師現場針對寵物商店的業務，組織一個DDD的工作坊（event storming），大致過程如下：

• 識別領域事件：
  針對一個寵物商店有哪些領域事件：添加寵物、提交訂單、收貨確認等等
• 按時間軸排序：
  針對上述領域事件根據時間軸進行排序
• 識別命令并關聯到事件：
  命令包括：用戶觸發命令、外部其他系統觸發命令、定時任務三類。
  用完成式描述命令，例如用戶已添加寵物到購物車、用戶已提交訂單等，最后將識別的命令貼在第一個觸發事件上，可能有多個事件對應同一個命令。
• 根據命令找到聚合邊界得到一個微服務：
  在時間軸上兩個命令之間的時間和第一個相關命令聚合為一個微服務。

界限上下文的識別必須由領域專家確認，團隊所有成員參加。這樣利于大家達成共識。

關于event storming和DDD的擴展資料：
https://groups.google.com/forum/#!forum/dddcqrs
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design

來自為知筆記(Wiz)

轉載于:https://www.cnblogs.com/cuiyunfeng/p/5716035.html

總結

以上是生活随笔為你收集整理的TID大会学习心得之敏捷软件架构-微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。