1.事件风暴
事件既事实,既在业务领域中已经发生的事件。
分析“已下单”
下面是用户点餐的分析
微服务设计:
1.先根据事件风暴进行领域建模
领域建模是将系统分了多个子域,每个子域有独立的业务场景。
2.基于领域建模进行上下文的设计。
每个子域的实现就是“限界上下文”,子域之间的联系就是上下文地图。
领域事件通知
异步消息通知各个微服务
聚合
聚合根唯一入口
判断是不是聚合
工厂
仓库
如果创建订单;
订单中会保存多个订单明细,通过仓库进行统一的保持
通过仓库来查询
查询订单
贫血模型设计VS充血模型
比如订单这个领域,
贫血:订单详情,订单都是各自的DAO,service
充血:只有订单Service,订单和订单详情同时增删改,数据的返回有仓库,调用各自的DAO,拼接好数据后进行返回。由于有些场景需要查订单明显,通过订单来查比较麻烦,可以直接查订单详情的数据。
查询难题
多个微服务提供数据后拼接。为了提高效率,可以增加一些关联性的冗余字段