领域驱动实践 营销系统建模
1. 领域驱动概述
1.1 领域驱动设计
DDD领域驱动设计详解:https://blog.csdn.net/m0_37583655/article/details/117565641
1.2 领域驱动建模
关于领域建模从三个角度解释下,什么是领域建模,为什么要领域建模,怎么样领域建模。
首先是什么是领域建模,领域建模就是对某个领域创建模型的过程,这里可能还会有疑问,创建什么模型,就是对某个行业分析以后梳理出来的业务逻辑总结,业务逻辑是看不见摸不着,但是却现实存在的东西,建模的作用就是可视化的展现出来它的逻辑分析。
其次是为什么要领域建模,只有通过梳理总结某个领域,你才能查漏补缺,进而对某个领域全面认识,只有充分认识某个领域才能更好的领域划分,找出边界,充分考虑其扩展性可维护性问题,试想一下一头雾水开发一个你都不知道的东西,你能划分好领域边界,能保证其扩展维护性吗。
最后是怎样领域建模,领域建模大致分为两部分,分别是战略设计与战术设计,战略设计主要从高层"俯视"我们的软件系统,帮助我们精准地划分领域以及处理各个领域之间的关系;而战术设计则从技术实现的层面教会我们如何具体地实施DDD。战略设计负责与领域专家一起,统一语义,找出边界上下文,领域划分,战术设计根据战略定义的统一语言,边界以及领域划分,进行落地需要的领域建模找出实体,值对象,聚合根,领域服务划分。找出需要提供那些领域服务。领域事件需要具备那些可扩展能力。基础设施层需要提供那些能力。
3. 营销领域建模
3.1 战略设计
3.1.1 领域划分
领域:营销系统
子域:活动管理,工具管理,策略管理
3.1.2 统一语义
活动:线上或者线下创办的营销活动。
活动类型:B端活动C端活动。
定向地域人群:活动指定的人群,地域特征。
市场线索:投放三方广告后获取的线索信息。
销售线索:三方线索数据完善清洗之后可以直接分配给销售跟进的线索。
3.1.3 有界上下文
3.1.4 领域场景分析
1.业务用例
2.系统用例
3.数据建模
数据库ER图
4.业务用例与系统用例的区别
这里可能很多人存在误解,认为系统用例就是业务用例的细分,其实不是这样的,业务用例是完全站在业务的角度考虑问题,是需求的直接体现,而系统用例则是站在系统建设者的角度,是需求的实现方式。比如客户取银行存取款,借贷款,所以业务用例只有这四个操作,但是系统用例则不一样,借款举例,客户借款需要信贷系统首先输入客户基本信息,征信系统获取征信报告,评级系统进行信用评级,审批系统进行放款审批,放款后还需要风险预警等等,这就是借款的系统用例要考虑做的事。
3.2 战术设计
3.2.1 领域模型
根据边界上下文,领域划分等找出实体值对象聚合聚合根。
3.2.2 领域服务
接口 | 接口名称 | 请求对象 | 响应对象 |
---|---|---|---|
create | 创建活动 | createReqDTO | createRespDTO |
upper | 上架活动 | upperReqDTO | upperRespDTO |
lower | 下架活动 | lowerReqDTO | lower RespDTO |
– | – | – | – |
3.2.3 领域事件
领域事件可以使系统更具可扩展性,并避免任何耦合–一个聚合体不应该决定其他聚合体应该做什么,以及时间耦合–展会预约成功完成并不一定参与完成。展会活动,线上预约,线下签到形成业务闭环,线下签到触发预约参与成功,否则参与失败。
3.2.4 基础设施
在DDD模式中,基础设施层被用来将核心业务领域与技术实现细节分开。通常,该层采用反污层(ACL)模式。以领域存储库为例。其中也包括缓存,三方都由基础设施层统一处理封装。
//通过仓储层实现数据操作
interface ActivityRepository{
save(Activity activity);
update(Activity activity);
query(Activity activity);
}