基础篇 为什么要选择DDD DDD有助于更好地理解业务、降低开发风险、提高质量、加速开发，以及更好地适应复杂领域。 领域、子域、核心域、通用域和支持域 领域和子域 " 在领域驱动设计中，领域和子域是两个重要的概念，用于帮助组织和划分软件系统的不同部分，以便更好的理解和设计系统。" 领域 领域是指问题领域或业务领域，它代表了软件系统所要解决的现实世界的一部分。

使用案例 " 上一讲，我们介绍了DDD领域驱动一般的代码分层结构。本文以一个支付功能为案例，讲述如实使用领域驱动的代码结构实现一个支付功能。" 需求背景 假设XXX系统有一个支付功能，该功能支持系统所有业务的支付操作，并且支持支付单取消，重新支付等功能。 大概流程如下： 将每一个流程再细化 业务系统触发支付操作：可以是同步接口，也可以是mq异步交互，也可以将

实战篇 " 查阅相关资料，DDD的专业名词特别多，在不结合代码和业务的场景下，理解起来很困难。本文从代码的角度出发，简述了DDD 四层架构的具体职责" 服务分层 这些目录的职能和代码形态是这样的。 Interfaces（用户接口层）： 它主要存放用户接口层与前端交互、展现数据相关的代码。; 和前端直接交互的逻辑在这里，例如：controller DTO 等相

解释器模式 四则运算问题 通过解释器模式来实现四则运算，如计算a + b - c的值，具体要求 1. 先输入表达式的形式，比如a + b + c - d + e，要求表达式的字母不能重复 2. 在分别输入a, b, c, d, e的值 3. 最后求出结果：如图 传统方案解决四则运算问题分析 1. 编写一个方法，接收表达式的形式，然后根据用户输入的数值进行解析

备忘录模式 游戏角色状态恢复问题 游戏鱼色有攻击力和防御力，在大战 Boss 前保存自身的状态（攻击力和防御力），当大战 Boss 后攻击力和防御万下降，从备忘录对象恢复到大战前的状态 传统方案问题分析 1. 一个对象，就对应一个保存对象状态的对象。这样当我们游戏的对象很多时，不利于管理，开销也很大 2. 传统的方式是简单地做备份，new出另外一个对象出来，

中介者模式 智能家庭管理问题 1. 智能家庭包括各种设备，闹钟、咖啡机、电视机、窗帘等 2. 主人要看电视时，各个设备可以协同工作，自动完成看电视的准备工作，比如流程为： 闹铃响起 => 咖啡机开始做咖啡 => 窗帘自动落下 => 电视机开始播放 传统方案解决智能家庭管理问题 即：仅可以通过闹钟响起，再去通知别的家电，而不可以反向操作或者定制别的流程 传统方

观察者模式 天气预报需求 具体要求如下： 1. 气象站可以将每天测量到的温度，湿度，气压等等以公告的形式发布出去（比如发布到自己的网站或第三方） 2. 需要设计开放型 API，便于其他第三方也能接入气象站获取数据 3. 提供温度、气压和湿度的接口 4. 测量数据更新时，要能实时的通知给第三方 传统方案解决天气预报需求 WeatherData类 通过对气象站项

迭代器模式 学校院系展示需求 编写程序展示一个学校院系结构： 需求是这样，要在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系。如图： 问题分析 1. 将学院看做是学校的子类，系是学院的子类，这样实际上是站在组织大小来进行分层次的 2. 实际上我们的要求是：在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系，因此这种方

访问者模式 测评系统项目需求 将人、观众分为男人和女人，对歌手进行测评，当看完某个歌手表演后，得到他们对该歌手不同的评价（评价有不同的种类，比如成功、失败等） 传统方案：即每打一次分，man类通过ifelse，判断是否给成功或者失败，woman同理。 传统方式的问题分析 1. 如果系统比较小，还是 ok 的，但是考虑系统增加越来越多新的功能时，对代码改动较大

命令模式 智能生活项目需求 1. 我们买了一套智能家电，有照明灯、风扇、冰箱、洗衣机，只要在手机上安装 APP 就可以控制这些家电的工作 2. 这些智能家电来自不同的厂家，我们不想针对每一种家电都安装一个 APP 分别控制，我们希望只要一个 APP 就可以控制全部智能家电 3. 要实现一个 APP 控制所有智能家电的需要，则每个智能家电厂家都要提供一个统一的