用户付款功能第二个版本的设计实现

折扣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。
• 重要：需要记录的重要的内容。
• 选餐只是一个动作（查询），因此不是一个领域事件的概念。

领域事件分析

为每一个领域事件去分析，上图为【下单领域事件】：

• 下单动作用蓝色表示
• 需要有事件的触发者
  
  

问题域、子域与限界上下文

主题域：核心功能
支撑域：支持主题域的模块，如用户注册