# DDD领域驱动设计

**Repository Path**: wu-guozhi/ddd_fastapi_template

## Basic Information

- **Project Name**: DDD领域驱动设计
- **Description**: 跟着https://www.bilibili.com/video/BV1eKpizeEnb尚学堂的教学视频，学习DDD领域驱动设计
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-01-28
- **Last Updated**: 2026-01-28

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README



# DDD FastAPI 模板

这是一个基于领域驱动设计（DDD）架构模式的 FastAPI 项目模板。

## 项目简介

本项目旨在提供一个简洁的 FastAPI 应用模板，采用 DDD 架构模式组织代码结构，方便快速启动新的 API 项目开发。

## 功能特性

- 🚀 **高性能**: 基于 FastAPI 框架，充分利用 Python 异步特性
- 📐 **DDD 架构**: 遵循领域驱动设计原则，代码结构清晰易维护
- 🔧 **易于扩展**: 模块化设计，便于添加新功能和领域服务
- 📝 **接口测试**: 内置 HTTP 测试文件，方便接口调试

## 快速开始

### 环境要求

- Python 3.7+
- FastAPI
- Uvicorn（ASGI 服务器）

### 安装依赖

```bash
pip install fastapi uvicorn
```

### 启动服务

```bash
uvicorn main:app --reload
```

服务启动后，访问 `http://localhost:8000` 查看应用。

## API 文档

FastAPI 自动生成交互式 API 文档：

- **Swagger UI**: `http://localhost:8000/docs`
- **ReDoc**: `http://localhost:8000/redoc`

## 接口说明

### 根路径

```http
GET /
```

返回应用欢迎信息。

### 问候接口

```http
GET /hello/{name}
```

**路径参数**
- `name`: 名称

**响应示例**
```json
{
    "message": "Hello, {name}!"
}
```

## 项目结构

```
├── main.py              # 应用入口，包含 API 路由定义
├── test_main.http       # HTTP 测试文件
├── .gitignore          # Git 忽略配置
├── .idea/              # IDE 配置目录
```

## 测试

使用 `test_main.http` 文件进行接口测试，可直接在支持 HTTP 文件的编辑器（如 PyCharm、VS Code）中运行。

## License

本项目基于 MIT License 开源。

## 贡献

欢迎提交 Issue 和 Pull Request 来完善这个模板。





## DDD（Domain-Driven Design） 领域驱动设计 

https://www.bilibili.com/video/BV1eKpizeEnb

#### 55，了解DDD领域驱动设计的核心概念

1. DDD的核心思想

- **业务优先**：先搞懂业务是怎么运作的，而不是一上来就建表
- **统一语言**：程序员、产品经理、业务方用同一个词描述同一个东西
- **边界清晰**：把大系统拆分成几个“小王国”，每个王国自己管自己

2. DDD核心概念

- **领域：**软件要解决的哪个业务范围
- **通用语言：**团队里所有人（程序员、产品经理、测试等）约定好的一套“黑话”。讨论业务、写代码、写文档都用这套话，不准出现第二种说法。DDD的基石。
- **限界上下文：给“通用语言”划界限**。同一个词，在不同的部门（上下文）里，意思可能完全不同。界限上下文就是把这些部门隔开，让每个部门内部用自己的“方言”而不会混乱。

![image-20260128212957328](assets/image-20260128212957328.png)

关键点：你不能把这三个上下文的"订单"混在一起设计成一个巨无霸Order类，会复杂到爆炸。限界上下文就是告诉你，应该把它们当成三个不同的东西来开发，甚至可以做成三个不同的微服务。这是降低复杂度的超级大招。

- **实体：有唯一ID的东西**，你看重的是“他是谁”，而不是它“是什么样”。它会变化，但它的身份ID不变。
- **值对象: 没ID, 只看属性值的东西。**你看重的是“它是什么样”, 如果两个东西的所有属性值一样, 就可以认为是它们是同一个东西。

![image-20260128213018360](assets/image-20260128213018360.png)

- **聚合根：一组相关对象的“老大”。**外部只能通过它来访问这组对象，它是保证业务一致性的边界。

![image-20260128213025398](assets/image-20260128213025398.png)

例如A是老大，A1、A2是A的小弟。修改A1要通过A.modify_a1()方法才行。

**为什么需要聚合根？**

![image-20260128213041272](assets/image-20260128213041272.png)

- **领域服务：**处理那些不属于任何实体/值对象的业务逻辑，通常是跨聚合的、无状态的、需要协调多个领域对象的操作。

![image-20260128213110879](assets/image-20260128213110879.png)



#### 56，DDD领域驱动设计的分层架构

DDD领域驱动设计推荐的分层架构，各层职责明确、依赖单向，确保业务核心（领域层）不受技术细节污染。

![image-20260128213130295](assets/image-20260128213130295.png)

##### 一，**用户接口层（User Interface Layer）**

1. **别名：**表现层，Web层，接口层，Controller层

2. **职责：**

  ​	2.1 接收外部请求（如HTTP、RPC、CLI）

  ​	2.2 解析输入参数（如JSON、表单）

  ​	2.3 执行基础校验（如非空、格式）

  ​	2.4 调用应用层服务完成业务操作

  ​	2.5 返回响应结果（如JSON、页面）

3. **不包含：**

  3.1 业务规则判断

  3.2 领域逻辑

4. **依赖:**
   4.1 仅依赖应用层（调用应用服务）。
     4.2 示例OrderController -> PlaceOrderService



##### 二，应用层（Application Layer）

1. 别名：用例层、服务门面层

2. 职责：
   2.1 协调领域对象完成一个完整的业务用力（如下单、转账）

   2.2 处理事务边界（如开启事务）
   2.3 发布领域实践

   2.4 转换DTO（数据传输对象）

   2.5 不包含可信业务规则（只指挥，不决策）

   

3. 组件示例：

​	3.1 应用服务（PlaceOrderService）

​	3.2 Command/Query对象

​	3.3 DTO（Data Transfer Object）

4. 依赖：

​	4.1 依赖**领域层**（使用实体、聚合、领域服务)

​	4.2 依赖**基础设施层**（获取Repository实现）

​	4.3 被**用户界面层**调用



##### **三，领域层（Domain Layer）**

1. 别名：模型层、核心层

2. 职责
   2.1 包含系统的核心业务逻辑和规则

   2.2 定义领域模型：
   	实体
   	值对象
   	聚合根

   ​	领域服务

   ​	领域事件

   2.3 保证业务一致性（如订单金额不能为负）

   2.4 不依赖任何外部框架（如Djiango、FastAPI、SQLAlchemy）

3. 关键原则：

   3.1 业务逻辑必须在这里实现

   3.2 聚合根负责维护内部一致性

4. 依赖

   4.1 无依赖（理想情况下不依赖其他层）

   4.2 被**应用层**调用

四，基础设施层（Infrastructure Layer）

1. 别名：数据访问层、技术实现层

2. 职责：

   2.1 提供技术实现，支撑上层运行

   2.2 实现领域层定义的接口。例如：OrderRepositroy接口的具体实现（如JPA、MyBatis）；消息队列发送器（如KafkaProducer）；外部API调用（如支付网关）

   2.3 处理数据库、缓存、文件、邮件等底层操作

3. 组件示例：

   3.1 Repository实现类

   3.2 事件发布器

   3.3 第三方客户端

4. 依赖

   4.1 依赖**领域层**（实现其接口）

   4.2 依赖**应用层**（如监听应用事件）

   4.3 被**应用层**和**领域事件处理器**调用

![image-20260128213154749](assets/image-20260128213154749.png)

人多、业务复杂时候才可以用DDD。



#### 57_DDD的项目基础设置

![image-20260128213246443](assets/image-20260128213246443.png)