架构师篇-8、运用事件风暴进行业务领域建

如何成为优秀架构师？

需要有一定的技术积累，但是核心是懂业务。
具备一定的方法，并且有很强的业务理解能力。

技术架构师：形成技术方案，做的更多的是底层的平台，提供工具。
业务架构师：解决方案架构师，理解业务需求用户痛点，形成解决方案。更接近客户。

架构师：

• 接近客户
• 理解业务
• 大局观：站在更顶层的角度规划系统，不断规划、不断抽象。
• 技术：互联网、大数据、AI、5G-物联网

关键难题：

• 如何快速有效地学习业务领域知识？
• 如何深入地理解与挖掘业务痛点？
• 如何通过技术的手段落地业务？

领域驱动的解决之道

敏捷团队将每个模块设计成微服务

中台构建

通过业务抽象，建立可复用的业务中台。

淘宝、天猫都有基础交易平台的需求。

抽出可复用的平台能力，搭建能力中台。

在做中台建设之前需要先梳理出各自的业务（领域模型），再抽取出共性的内容。
阿里的中台建设：

业务中台：能力中心

通过微服务架构搭建系统

频繁的变更带来软件质量的下降

软件频繁变更的demo：电商网站付款功能

需求不断变更：增加商品折扣功能、增加VIP会员权益、增加支付方式、…

最终的结果使得代码混乱。

以上的问题是软件发展的必然规律：

简单软件 VS 复杂软件

一般情况下的软件迭代都是由简单需求到复杂需求，因此代码的迭代就会出现腐败。如果第一次就提出的是复杂需求，那可能第一次就能实现复杂软件应该有的架构。

软件退化的根源

软件退化的根源是需求变更之后，没有进行代码的解耦和扩展就会出现软件退化。

如电商网站付款功能，如果直接在简单软件上做if else的迭代的话，软件质量就会下降。

领域模型及领域建模思想

将软件设计和真实世界结合起来


在原来的订单上增加一条订单明细时，应该直接保存整个订单，对订单作为一个整体提交。

领取驱动设计的过程

• 领域建模的过程
• 领域模型指导数据库设计
• 领域模型指导软件设计

原始需求

第一个版本的领域模型

领域模型所有描述的内容都是业务，不包含技术。领域模型是对业务的抽象。

通过一个配置文件描述领域模型之间的关系

不使用在对象中使用注解的原因是减少业务代码对底层框架的耦合。

第一个版本的程序设计

付款功能第一个版本的实现