采用DDD时应分Domain、Application、Infrastructure、Presentation四层，每层职责分明且仅依赖下层。Domain包含实体、值对象、聚合根及领域事件，不依赖其他层；Application协调业务用例，调用领域对象但不含业务规则；Infrastructure实现仓储、事件发布等技术细节；Presentation负责接收请求并返回响应。推荐将各层拆为独立项目以强制依赖控制，确保Presentation无法直连Domain。领域模型需体现真实业务概念，聚合根继承Entity<TId>，值对象使用ValueObject基类，仓储接口定义在Domain，实现在Infrastructure。应用服务作为外部与领域交互的桥梁，接收DTO或命令，执行业务操作并返回结果，建议结合MediatR实现CQRS。Infrastructure通过EF Core实现数据访问，注册依赖服务，并集成消息队列等外部系统。Presentation轻量化处理协议转换，控制器仅做请求映射与响应封装，避免嵌入业务逻辑。整体结构保障领域核心独立，提升可维护性与团队协作效率。
在C#项目中采用领域驱动设计（DDD）时，合理的项目结构能提升代码可维护性、可测试性和团队协作效率。核心思想是围绕业务领域建模，通过分层架构隔离关注点，避免技术细节污染业务逻辑。
1. 分层结构划分
典型的DDD分层包含以下四个核心项目（或文件夹），每一层只能依赖其下层：
- Domain（领域层）：存放实体、值对象、聚合根、领域服务、领域事件和仓储接口。这是业务核心，不依赖任何其他层。
- Application（应用层）：协调领域对象完成业务用例，包含应用服务、DTO、命令/查询模型和事务控制。它调用领域层，但不包含业务规则。
- Infrastructure（基础设施层）：实现仓储接口、发送领域事件、提供邮件服务、数据库访问（如EF Core）、缓存等。它依赖具体技术栈，并实现上层定义的契约。
- Presentation（表现层）：Web API、MVC控制器、Blazor页面或WPF界面。只负责接收请求和返回响应，不处理业务逻辑。
2. 项目组织方式（推荐多项目方案）
将每层拆分为独立的.NET项目，强制编译期依赖控制：
/src /MyApp.Domain → Class Library (.NET Standard or .NET) /MyApp.Application → Class Library /MyApp.Infrastructure → Class Library /MyApp.WebApi → Web API Project
这种结构确保Presentation不能直接访问Domain，必须经过Application层，防止业务逻辑泄露到接口层。
3. 领域层设计要点
领域模型应体现真实业务概念：
- 聚合根继承
Entity<TId>基类，封装ID比较逻辑。 - 值对象使用
ValueObject基类，重写Equals以属性相等为准。 - 领域事件实现
IDomainEvent接口，在聚合内部触发。 - 仓储仅定义接口（如
IUserRepository），具体实现在Infrastructure层。
4. 应用层职责清晰
应用服务（Application Service）是外部系统与领域模型之间的桥梁：
- 接收DTO或命令对象（如
CreateUserCommand）。 - 调用领域服务或聚合方法执行业务操作。
- 通过仓储保存变更，发布集成事件（非领域事件）。
- 返回结果DTO，不暴露领域实体。
推荐结合MediatR实现CQRS模式，分离查询与命令逻辑。
5. 基础设施层实现解耦
该层负责对接外部系统：
- 使用EF Core实现仓储，配置实体映射和数据迁移。
- 依赖注入注册所有服务，例如在
Program.cs中添加services.AddScoped<IUserRepository, UserRepository>(); - 可引入消息队列、第三方API客户端等，作为领域事件的发布通道。
6. 表现层轻量化
Web API项目仅做协议转换：
- 控制器接收HTTP请求，映射为命令或查询。
- 通过MediatR或应用服务执行操作。
- 返回标准化响应（如Result类型或ProblemDetails）。
- 避免在Controller中编写业务判断。
基本上就这些。关键在于保持各层边界清晰，让领域模型成为项目的核心资产，而不是被技术框架牵着走。
