领域驱动设计DDD

目录

一、几个概念

1. 子域，核心子域、支撑子域、通用子域

2. 限界上下文

3. 问题空间和解决方案空间

二、理解

1. 意义

2. DDD落地实现的相关知识

1）In-Memory缓存

2）事件驱动实现解耦、异步

3）DCI架构

3. 六边形架构 + 面向对象设计

4. 代码分层

一、几个概念

1. 子域，核心子域、支撑子域、通用子域

2. 限界上下文

含义：业务流程的领域空间。

特点：高内聚、低耦合

3. 问题空间和解决方案空间

问题空间：核心子域+其他子域

解决方案空间：多个限界上下文（领域模型）

二、理解

1. 意义

传统J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法，被比喻成失血模型。

DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。

2. DDD落地实现的相关知识

1）In-Memory缓存

基于Java内存模型，DDD不再面向关系数据库中数据表编程，而是真正直接面向模型对象编程。

区别于对数据库中数据的操作，DDD更注重的是对状态对象的操作（DDD+Cache）。

状态对象：

• 状态分两种：活动的状态对象和持久化的状态。而数据库中的数据只是状态的一种持久化结果，而Java系统 运行时，我们更多的可能是和一种活动的状态打交道，这种活动的状态存在内存中，而不是持久化到硬盘上，当然，需要时你可以通过数据库/文件持久化到硬盘上。
• 状态的危险还会发生在多线程环境下，当多个线程对同一个内存中状态写操作时，这时怎么办？如果这个状态持久化在数据库中，我们会依赖数据库提供的强大事务机制防止这种并发死锁，但是如果是在内存中，就很难办，因此，我们就尽量避免发生这种多线程同时访问一个状态的现象。
• 状态的生命周期在J2EE中目前有三种：Request/Session和Application，Request是每个客户端发出的一次请求，这是J2EE系统中最基本的事件激活单元， 当服务器端推出一个页面到客户端时，意味着这个Request的结束。那么如果我们的状态保存在Request中，意味着在request结束之前，这个请求经历的任何一个环节都可以对这个状态（对象）进行操作。

2）事件驱动实现解耦、异步

3）DCI架构

DCI: Data数据, Context场景, Interaction交互。

对象被使用时需要的属性和行为不必一定要在编写代码时写入，而是在运行时再注入或MiXIN混合进去。

3. 六边形架构 + 面向对象设计

领域模型层：Domin.Model

4. 代码分层

• DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。

• DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。

• BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。

• AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。

• VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。

• Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。

 

参考：https://www.jianshu.com/p/89dfcd672d43

https://www.jdon.com/ddd.html

https://www.jdon.com/dci.html

https://www.jdon.com/38266#23127442

https://www.jdon.com/eda.html

https://www.jdon.com/cache.html

https://www.jdon.com/artichect/state.htm

https://mp.weixin.qq.com/s?__biz=MzI4MDYwMDc3MQ==&mid=2247487019&idx=3&sn=651d2d9ebe0909dfd1bd649c6c59fe68&chksm=ebb74787dcc0ce919477762180321efddcf141e4ade6de3c76b4d15b7ea56825e9a32169bde5&scene=0&xtrack=1#rd