DDD领域驱动设计(包括事件驱动)简单理解版本(代优化)

简单分享下自己的理解,不一定对,大佬可喷
比如我们有一个FileObj 这是一个文件对象
里面存储了文件URL 、 ID 等属性
这时候我们给它定义一个公开的方法为
pullFileForBytes()
将文件url拉取为字节对象,并且这个方法由工具类实现,因为要考虑到复用性
这样拿到这个对象的时候通过简单调用下方法就可以拿到文件字节数组
同理
Order类可以定义createOrder()方法去创建订单

事件驱动

事件驱动感觉和消息驱动很像,但是事件驱动更加规范

事件元数据

一个事件里面固定的都会有几个字段,我们可以将他们统称为metadata或者headers
分别为

eventId 事件id ==> 这个在消费端可以做幂等
eventType 事件类型
eventCreatedTime 事件发生时间

通过eventId贯穿整条链路

事件溯源

所有的事件都会在派发前入库
event_log 里面会记录所有的事件 类似本地消息表(事件发送状态等字段) 但是和本地消息表不同的是 它会记录event_content 就是发送事件的数据 这样整个链路的操作内容都会被记录

事件驱动一般用MQ实现 比如Kafka RocketMq RabbitMQ等

优点

  • 解耦
  • 可靠性高
  • 负载高

缺点

  • 暂时没想到

事件驱动流程

前端控制器=> Command命令=> 业务操作=> dispatchEvent分发事件=> 事件监听

业务中的实际应用:
比如某个员工离职了,需要在多个业务里面将他的状态标记为离职或者删除
那么我们只需要监听这个事件做出对应的业务处理即可
尤其是微服务中,如果由离职业务去主动向多个微服务去调用对应的业务处理是一个很蠢的事情,扩展性低
但是如果只是推送一个离职事件里面包括这个员工的id 那么扩展性就会非常高。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值