002 根据DDD进行重构系统
进行模块划分
业务逻辑入手
- handler层 部分业务逻辑下沉到微服务-沉淀为领域service
- handler层 部分业务逻辑整合到应用服务模块
Mapper
- Mapper 已使用tkmybatis
Model
- model 新增自身逻辑(校验、等),划分到 领域model
- model 北向 , 面向数据库
- message 南向 ,面向业务层
领域发现
那领域模型是怎么一步一步确定下来的呢?推荐两种比较常用的领域发现方法:事件风暴与四色建模法。
一、事件风暴
Event Storming(事件风暴)是一种轻量级的系统分析方法,基于 DDD 的概念,能够为我们梳理系统中的各种相关元素,其中包括了核心的 Aggregate。它能够帮助开发人员梳理核心的业务对象,从某种程度上来说就是就是领域对象中的聚合。
描述产品愿景
产品愿景的主要目的是对产品顶层价值的设计,使产品目标用户、核心价值、差异化竞争点等信息达成一致,避免产品偏离方向。
产品愿景的参与角色:领域专家、业务需求方、产品经理、项目经理和开发经理。
事件风暴关注点
事件:某个动作的结果
属性:事件的输入、输出
命令:某个动作
实体:命令的触发者
简单理解就是谁(实体)使用什么(输入)做了什么(命令、动作)产生了什么(输出)影响了什么(事件)。
二、四色建模法
通过还原业务逻辑事件,依据是否影响公司的运营和发展,确定凭证作为时标型对象,并补全相关描述的建模方法。四色建模法一般运用于问题分析建模。
四色建模是哪四色?它包括——
时标型(Moment-Interval)对象:具有可追溯性的记录运营或管理数据的时刻或时段对象,用粉红色表示;
PPT(Party/Place/Thing)对象:代表参与到流程中的参与方/地点/物,用绿色表示;
角色(Role)对象:在时标型对象与 PPT 对象(通常是参与方)之间参与的角色,用黄色表示;
描述(Description)对象:对 PPT 对象的一种补充描述,用蓝色表示。
分析的五个步骤
- 找到溯源事件
- 确定时标型对象
- 找到周围的PPT对象
- 找到角色
- 补全描述对象
四色建模法案例:
跨库关联查询解决方案
方案一:数据冗余
这是最简单常用的一种解决方案——以空间换时间,把需要关联查询的条件冗余存储在需要查询的库。
举个例子,商品与商品类目被拆到两个独立的服务与数据库中,两者通过类目编码关联,产品想通过类目名称对商品分页查询,这时我们可以把类目名称冗余到商品表存储,给它加个数据库索引即可。
做宽表
方案二:数据补填
结合Wrapper设计模式,一般在Dao层实现数据聚合——本地库分页查询完数据后,通过查询条件判断是否需要填充关联数据,若需要则通过跨服务查询相关联的服务,再对各个服务的数据进行填充组装,最后返回。
- 原文作者:知识铺
- 原文链接:https://geek.zshipu.com/post/DDDsz/002-%E6%A0%B9%E6%8D%AEDDD%E8%BF%9B%E8%A1%8C%E9%87%8D%E6%9E%84%E7%B3%BB%E7%BB%9F/
- 版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可,非商业转载请注明出处(作者,原文链接),商业转载请联系作者获得授权。
- 免责声明:本页面内容均来源于站内编辑发布,部分信息来源互联网,并不意味着本站赞同其观点或者证实其内容的真实性,如涉及版权等问题,请立即联系客服进行更改或删除,保证您的合法权益。转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。也可以邮件至 sblig@126.com