DDD--领域驱动设计第一次亲密接触笔记

领域驱动设计：软件核心复杂性应对之道

概念

在MVC的编码过程中，我们关心的数据流的流动，更像是一种面向过程的实现。各个组件依托于Spring的单例进行方法调用。而且MVC的entity多是用lombok处理后的贫血模型。贫血模型将模型和操作进行分离，破坏了对象的封装性。
那么来谈谈DDD（领域驱动设计）主要是用来指导如何解耦业务系统，划分业务模块，定义业务领域模型及其交互。领域驱动设计这个概念并不新颖，早在 2004 年就被提出了，到现在已经有十几年的历史了。不过，它被大众熟知，还是基于另一个概念的兴起，那就是微服务。DDD与mvc最大的区别在于Service层。 DDD 开发模式中，Service 层包含 Service 类和 Domain 类两部分。Domain 就相当于贫血模型中的 BO。不过，Domain 与 BO 的区别在于它是基于充血模型开发的，既包
含数据，也包含业务逻辑。而 Service 类变得非常单薄。

充血模型（Rich Domain Model）
正好相反，数据和对应的业务逻辑被封装到同一个类中。因此，这种充血模型满足面向对象的封装特性，是典型的面向对象编程风格。
既然充血模型把很多操作都通过操作封装完成了，那么service的作用是什么？

• 与dao交流，获取数据库数据，转化为领域模型。完成业务逻辑存回数据库
• 跨领域的业务聚合功能
• 非功能性与第三方系统交互，如幂等，事务，邮件，日志，RPC等

既然聊到了这里，我们再来看看对业务的分析过程：

• 第一轮基础分析

• 第二轮分析优化–业务重点

• 第三轮分析优化–异常分析 2/8原则 影响分析

• 第四轮分析优化–安全性，开发成本，系统性能影响

• 确定需求

• 划分职责确定类
  首先根据需求描述，把其中涉及到的功能点一一罗列，功能点职责相近的分析能否归于一个类并建立名词字典。

• 定义类及其属性与方法

• 定义类之间的关系

• 类组装并提供执行入口

YAGNI （You aren’t gonna need it） 不要做过度设计
KISS （keep it simple and stupid）
DRY （Don’t repeat youself）

分层表示¹
领域驱动设计²
要解决的问题
提炼领域知识
界定上下文

模型

模型和实现的绑定，建立了一种基于模型的领域或者问题分析语言
开发一个蕴含丰富知识的模型。对象具有行为和强制性规则。模型并不仅仅是一种数据模式，它还是解决复杂问题不可或缺的部分。
提炼模型。在模型日趋完整的过程中，重要的概念不断被添加到模型中，但同样重要的是，不再使用的或不重要的概念则从模型中被移除。当一个不需要的概念与一个需要的概念有关联时，则把重要的概念提取到一个新模型中，其他那些不要的概念就可以丢弃了。
头脑风暴和实验。语言和草图，再加上头脑风暴活动，将我们的讨论变成“模型实验室”，在这些讨论中可以演示、尝试和判断上百种变化。

分层

参考：

---

1. https://www.jianshu.com/p/c405aa19a049 ↩︎

2. http://zhangyi.xyz/ ↩︎