关于DDD设计的一些实践思考

DDD全名，领域驱动设计。是一门软件设计理论，在面向对象的基础上进一步，作用是设计出低耦合、高内聚的软件产品，通过分层的设计思想，是软件达到扩展、性能、易读性；

业务建模和大数据建模的桥梁；

大家都觉得这是一个技术话题，完全错了，ddd的核心是业务，产品思维转变到技术思维；

高手DDD可以通过客户的语言表述，清晰准确的理解客户90%的诉求。并且量化，好记性不如烂笔头，不管是通过文档、图形、表格来量化出需求模型都是必须必须必须的。而且，你量化的东西，别人是否能看明白，别人都看不明白，你量化了的意义何在？不论你是什么岗位，首先想明白一件事，你的标的是谁？是你的同事？还是你的竞争公司？还是你在行业里的位置？格局有多大决定了你是否有入局高端玩家的入场券。

为了devops和低代码生成器的标准化规范前提；

为了清晰业务系统，清晰业务系统模型和后续大数据建模；

devops是根据DDD领域驱动的持续集成、测试、敏捷开发、交付；

1. 首先，需要对一个业务需求分析，创建领域模型；

2. 然后，将模型对象和业务逻辑，开发落实到四层代码当中的领域层domain；【应用层application、领域层domain、用户界面层interfaces、基础设施层infrastructure】

3. 再然后，理解一下概念

•     应用层application：全是接口interface没有接口的实现，和定时任务；

•     用户界面层interfaces：全是controllers和dto，也就是说这里controllers是对外提供的restful api,dto则是api带验证的入参对象；

•     基础设施层infrastructure：配置文件、工具包、数据库连接、权限、拦截器、过滤器、公共组件、全局变量、全局常量等；

•     pom.xml:引入依赖的外部包、外部公共组件；

•     业务逻辑、业务过程、业务行为：可以理解业务逻辑是由多个业务行为（也叫业务过程）串联组成；

•     领域=聚合=表的全部内容=大圆圈；

•     领域对象=小椭圆=表字段=也可以是业务过程；

•     聚合根=聚合和聚合之间关联（主键、外键）=表名；

最后，分四层的目的，使得代码清晰，便于迁移。新项目复用的时候，只需要将领域层、应用层的代码拷贝出来，在新项目的用户界面层进行引用即可；多么清晰的代码结构：

 

如何设计聚合？简单说就是对业务需求的理解，抽离出业务行为，在然后对业务行为抽离出领域对象【大圆圈是聚合，小椭圆是领域对象】

 

 

举例：保单系统聚合的过程；

我们收到一个客户需求，首先不是画业务流程图，也不是先搞数据库设计，也不是先画产品原型；我们应该先做DDD领域建模，把客户的需求从语言文字量化到领域对象和业务过程，用图形化归纳起来，形成业务总体设计，一目了然。然后再建立业务流程图，再ER图，再原型，再架构，再开发；

 

领域模型是什么?图文详解小白也能上手领域模型图

1、对进销存系统建立领域模型
假设我们要为一家蔬菜店设计一套进销存系统，她为我们提供的业务描述是这样的：每天凌晨从蔬菜批发市场买胡萝卜、白菜、花椰菜、西兰花、西红柿、玉米、空心菜、生菜等等蔬菜，反正哪些好卖她就买回来卖。不宜存放的蔬菜，一般要当天卖出去。
通过上面这句话，我们对其进行分析并建立模型。
1)确定名词：凌晨、蔬菜批发市场、胡萝卜、白菜、花椰菜、西兰花、西红柿、玉米、空心菜、生菜、顾客。
2)确定业务实体：胡萝卜、白菜、花椰菜、西兰花、西红柿、玉米、空心菜、生菜。
3)共性分析：易氧化类（需当天卖出的属一个具体实例）：生菜、空心菜；不易氧化类：胡萝卜、白菜、花椰菜、西兰花、西红柿、玉米。
4)确定领域模型：通过这样进一步的分析得出领域模型——蔬菜进销存领域模型。