2018年可视化的遗留系统微服务改造.pdf

1、?CONTENTS01引言02可视化的认识遗留系统03可视化的划分遗留系统04可视化的拆解遗留系统引言遗留系统、微服务架构任何人类的设计都会腐化软件当然也不例外拆成微服务微服务架构的九大特征通过服务进行组件化围绕业务能力组织做产品而不是做项目智能端点与傻瓜管道去中心化地治理技术去中心化地管理数据基础设施自动化容错设计演进式设计可视化能帮我们什么掌握系统业务明确系统边界小步改造系统可视化的认识遗留系统C4模型、用户画像、用户旅程C4模型系统架构可视化国家级省级道路级市级C4模型系统架构可视化系统上 下文图容器图代码图组件图已可视化用户画像和旅程系统功能用户可视化用户画像用户旅程已可视化突出用户信

2、息，诉求和价值体现还原业务场景可视化的划分遗留系统领域驱动设计、事件风暴工作坊、服务画布好的设计低耦合如果做到了服务之间的松耦合，那么修改一个服务就不需要修改另一个服务。一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息。高内聚就是把相关的行为聚集在一起，把不相关的行为放在别处。如果你要修改某个服务的行为，最好只在一处修改。领域驱动设计领域驱动设计是一种处理高度复杂域的设计思想，试图分离技术实现的复杂性,围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题。团队应用它可以成功地开发复杂业务软件系统，使系统在增大时仍然保持敏捷。事件风暴工作坊-Event Sto

3、rming是一种领域建模的实践，是一种快速探索复杂业务领域的方法：-最初由Alberto Brandolini开发，经过DDD社区和TW的很多团队实践验证后，于2015年11月进入ThoughtWorks技术雷达Powerful：可以让实践者在数小时内理解复杂的业务模型Engaging：把带着问题的人和拥有答案的人共聚一堂构建模型Efficient：跟DDD的实现模型高度一致，并能快速发现Aggregate和 Bounded ContextEasy：标记都很简单，没有复杂的UMLFun简介正确的人：业务人员，领域专家，技术人员，架构师，测试人员等关键角色都要参与其中开放空间：有足够的空间可以将

4、事件流可视化，让人们可以交互讨论彩色即时贴：至少三种颜色活动准备寻找领域事件事件风暴命令风暴寻找聚合划分限界上下文什么是事件？为什么用事件？如何进行事件风暴？事件：领域专家关心的，在业务上真实发生的事例1:客户订单已提交例2:对账已完成，每月末夜间触发1.确定要进行事件风暴的业务场景，场景需要单一而且清晰；2.用“XXX已XXX”的格式在橙色便利贴上写下事件，工作坊参与者需要对事件定义达成一致；3.根据时间顺序把事件便利贴贴到白板上；4.如果一个事件有同步发生的其它事件，把其它事件放在事件下方；5.如果发现了业务中的问题点，用红色便利贴记录为什么是一个问题；6.以上步骤完成以后，再从最后一个事

5、件开始来反向验证事件的完整性（即：走查前后事件的关联关系，防止有些事件被遗漏）。通过事件的方式对过去发生的事情进行溯源，因为过去所发生的对业务有意义的信息都会通过某种形式保存下来。事件风暴能够让领域专家和工作坊参与者一起明确在业务上究竟是什么领域模型发生了什么改变，最终的软件系统需要关注业务过程中发生的业务数据的变化。事件风暴示例订单 已创建订单 已支付商城库存 已扣减仓库库存 已占用商品 已创建订单 已撤销商城库存 已增加出库单已 生成出库单已 发货投诉单 已创建投诉单已 处理商城库存 已编辑商品 已发布商品销售 价格已编辑订单 已发货补货申请 单已创建补货申请 单已审批入库单 已创建入库单

6、 已入库订单 已签收订单已 确认收货仓库库存 已扣减仓库库存 已增加商品已 编辑退货单已 创建退货单已 审核订单已 退货入库单 已创建入库单 已入库仓库库存 已增加寻找命令事件风暴命令风暴寻找聚合什么是命令？为什么用命令？如何进行命令风暴？命令：什么活动产生了事件 例1:提交客户订单例2:启动夜间对账事件是业务上的输出，命令是业务上的输入。命令以及相应角色可以明确最终软件系统会有哪些功能给外界使用。命令和事件将会在后续的环节中指导API的设计。1.将命令写在蓝色即时贴上，可以是 用户从UI界面进行的操作 外部系统触发 定时任务2.将命令贴在所产生的事件旁边；3.有的命令可能产生多个事件，将它们