用户付款功能第二个版本的设计实现
折扣Service和OrderService拆和不拆是由代码规模决定的。
单一职责原则(SRP)
- 软件系统中的每个元素只完成自己职责内的事,将其他的事交给别人去做
- “职责”通常人理解为一个事情,与该事情相关的事都是它的责任
一个职责是软件变化的一个原因
第二次需求变更
增加VIP会员功能
- 对VIP金卡和银卡会员进行不同的折扣
- 在支付时为VIP会员发放福利
- VIP会员可以享受某些特权
遇到需求之后,不要马上coding,而是先回到上一版本的领域模型。
付款功能第三个版本的实现
第三个版本的领域模型
第三次需求变更
增加更多的支付方式
- 支付宝支付
- 微信支付
- 工商银行支付
- 民生银行支付
- 广发银行支付
- 招商银行支付
第四个版本的领域模型
付款功能第四个版本的实现
领域驱动架构的设计实现
传统的领域驱动设计方式代码
前端:vue
数据接入层:controller
应用层:service
领域层:entity
基础设施层:仓库实现- repository
今后的设计思路:DDD+低代码。后续不需要写Controller和 Repository,只需要写vue、service、entity
演练领域驱动的设计过程
需求分析-》领域建模-〉设计编码
- 业务分析:统一语言与事件风暴
- 领域设计:服务、实体、值对象
- 微服务拆分:聚合、限界上下文文与领域事件
统一语言建模
业务规则
业务流程
业务痛点
诊断领域模型
事件风暴(Event Storming)
事件风暴是一种基于工作坊的实践方法,它可以快速发现业务领域中正在发生的事件,指导领域建模及程序开发。
它是Alberto Brandolini发明的一种领域驱动设计实践方法,被广泛应用于业务流程建模和需求工程。
基本思想是将软件开发人员和领域专家(最好的方式是客户,实际操作起来比较困难,一般都是产品经理)聚集在一起,相互学习。
为了让学习变得更容易,该方法的工作方式类似于头脑风暴,让事件风暴变得很有趣。
事件即事实(Event as Fact)
领域事件:即领域中发生的事实(fact)
在真实世界中,当满足某个条件时,某个发起者会触发某个事件,做某个事情。
事实(fact):是指那些已经发生过的事件。
鉴于过去已经发生的事实不会发生改变,因此信息系统可以将这些事实以信息的形式存储到数据库中,即信息就是一组事实。
事件风暴会议
- 事件风暴会议以完成领域模型为目标
- 参会人员:领域专家和软件开发人员
- 会议以探讨领域事件开始,从前往后依次梳理,以确保领域中所有事件都能覆盖
- 项目组成员不断增加各种命令与事件,进而思考与之相关的资源、外部系统与时间
- 识别模型中可能的聚合以其聚合根
- 将模型分配到各个限界上下文中,构建上下文地图
案例:在线订餐系统
领域事件
领域事件的定义:
- 过去发生:因此是已xx。
- 重要:需要记录的重要的内容。
- 选餐只是一个动作(查询),因此不是一个领域事件的概念。
领域事件分析
为每一个领域事件去分析,上图为【下单领域事件】:
- 下单动作用蓝色表示
- 需要有事件的触发者
问题域、子域与限界上下文
主题域:核心功能
支撑域:支持主题域的模块,如用户注册