TID大会学习心得之敏捷软件架构-微服务

敏捷微服务构建

王威： 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)