【DDD】初印象

这是我参与11月更文挑战的第2天，活动详情查看：2021最后一次更文挑战

一、前言

在实现需求的过程中，软件的业务逻辑也会越来越接近真实世界，使得我们的软件越来越专业，让用户感觉越来越好用。

• 但是，在软件越来越接近真实世界的过程中，业务逻辑就会变得越来越复杂，软件规模也越来越庞大。

• 软件退化的根源不是软件变更，软件变更只是一个诱因。

杜绝软件退化：两顶帽子

保持软件设计不退化的关键在于每次需求变更的设计，只有保证每次需求变更时做出正确的设计，才能保证软件以一种良性循环的方式不断维护下去。这种正确的设计方式就是“两顶帽子”。

0. 在不添加新功能的前提下，重构代码，调整原有程序结构，以适应新功能；
1. 实现新的功能。

有没有一种方法，让我们在第十次变更、第二十次变更、第三十次变更时，依然能够找到正确的设计呢？

有，那就是“领域驱动设计”。

那么，如何将真实世界与软件世界对应起来呢？这样的对应就包括以下三个方面的内容：

• 真实世界有什么事物，软件世界就有什么对象；
• 真实世界中这些事物都有哪些行为，软件世界中这些对象就有哪些方法；
• 真实世界中这些事物间都有哪些关系，软件世界中这些对象间就有什么关联。

在领域驱动设计中，就将以上三个对应，先做成一个领域模型，然后通过这个领域模型指导程序设计； 在每次需求变更时，先将需求还原到领域模型中分析，根据领域模型背后的真实世界进行变更，然后根据领域模型的变更指导软件的变更，设计质量就可以得到提高。

二、大白话 DDD

先来看下，传统软件设计过程：

0. 以数据库模型为核心：数据模型与物理模型对应
1. 确定数据库中表和字段
2. 建立 domain 包，创建对应的类
3. 创建 controller、service、dao、mapper（SQL），实现对应业务。

传统软件设计过程有什么问题呢？

没有一个清晰的业务模型。 按照此方法，做到中后期，有大量的数据库表，即对应的 controller、service、dao 和 mapper 也是大量的。 那么这个系统，让一个新人介入，很难快速上手。

举个栗子

现实中，启动汽车步骤大致可分为：

0. 按下按钮（发出启动命令）
1. 启动汽车引擎
2. 启动车子

那么在面向数据库设计，实际执行会如：

0. 调用 controller 中的 startCar() 方法
1. 调用 service 中的 startCar() 方法
2. 在 Driver表中插入启动记录，在 engine表中修改记录，在 car表中修改记录

有没有一种方式，把现实事物直接映射到代码中，让码农更好理解呢？

比如，底层封装了很多组件，用来完全模拟出真实世界的运行过程。

那么代码中，实体与实体的交互，即类与类的交互，应尽可能模拟出真是世界的情况：

• 把软件系统里的类和组件，从 controller、service、dao 和 SQL 解脱出来。
• 软件模拟了真实世界的运行情况，即使是后期维护，也更容易毅力

总结：说白了，提高抽象能力，统一话术。

\