领域驱动设计营销系统建模

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);
}