C#——意框架（结构说明）

模块目录结构详解：基于DDD思想的工程分层设计

一、整体框架说明

本文将结合工程约定与模块模板，详细说明module目录下各常见子项目/文件夹的核心职责、放置内容及设计原则。以下结构适用于多数基于DDD（领域驱动设计）思想的分层架构项目，可根据实际技术选型（如ORM框架）微调命名。

二、核心模块详解

核心模块是实现业务功能的基础，按职责从核心到外层依次分为领域层、应用层、基础设施层，各层通过明确的依赖关系解耦。

1. <Module>.Application：应用层实现

• 核心职责：应用层具体实现，向上层（Web/API）暴露能力，同时协调领域层完成各类业务用例（Use Case）的执行。

• 放置内容：

  • 应用服务的具体实现类（AppService）；

  • DTO映射配置（Mapster/AutoMapper 相关配置）；

  • 场景级别的业务逻辑代码；

  • 跨领域事务编排逻辑；

  • 权限校验、数据验证的应用节点；

  • 仅内部使用的请求/响应DTO。

• 典型示例：Application/Services/AccountService.cs（实现对应接口，通过调用领域管理器完成业务逻辑）。

2. <Module>.Application.Contracts：应用层契约

• 核心职责：定义应用层对外公开的API/客户端约束，实现接口与实现的解耦。

• 放置内容：

  • 应用服务接口（如 IAccountService）；

  • 输入/输出DTO（对外暴露的参数与返回值类型）；

  • 共享的API契约（API contract）；

  • 供其他模块或客户端引用的轻量类型。

• 关键说明：该项目可被上层（Web项目、客户端、其他模块）直接引用，且不携带任何实现依赖，是解耦上层与应用层实现的核心节点。

3. <Module>.Domain：领域核心层

• 核心职责：系统的领域核心，封装核心业务规则与领域模型，尽量避免依赖基础设施细节。

• 放置内容：

  • 聚合根（AggregateRoot）、实体（Entity）、值对象（ValueObject）；

  • 领域服务/领域管理器（如 AccountManager）；

  • 领域事件（Domain Event）；

  • 仓储接口（如 IUserRepository，仅定义接口，不包含实现）；

  • 领域异常、领域相关常量。

• 设计原则：核心业务规则必须放在此层，应用层仅负责业务流程的编排，不包含具体业务规则判断。

4. <Module>.Domain.Shared（或 Domain.Shared）：领域共享层

• 核心职责：定义模块共享的基础类型，可被 Domain 层和 Application 层共享，且无外部实现依赖。

• 放置内容：

  • 枚举类型、全局常量；

  • 通用DTO、小型工具类；

  • 配置选项类（若不依赖基础设施）；

  • 跨模块可复用的轻量类型。

• 核心作用：避免 Domain 层与 Application 层之间的循环引用，同时为多个项目提供统一的基础定义。

5. <Module>.SqlSugarCore：基础设施与持久化层

注：该层也可命名为 .EntityFrameworkCore、.Infrastructure 等，核心职责均为基础设施实现与持久化处理。

• 核心职责：实现持久化逻辑与基础设施细节，具体基于 ORM 框架（本文项目使用 SqlSugar）。

• 放置内容：

  • 仓储接口实现（如 UserRepository，实现 Domain 层定义的 IUserRepository）；

  • DbContext/SqlSugar 客户端配置；

  • 数据库表映射关系配置；

  • 数据库迁移脚本、种子数据；

  • 数据库相关扩展方法、SQL性能优化逻辑。

• 设计原则：所有与数据库、缓存、外部服务的具体调用均在此层实现，Domain 层仅依赖仓储接口，不涉及任何基础设施细节。

三、其他常见可选文件夹

以下文件夹为工程模板中常见的可选模块，根据项目规模与需求灵活增减：

• HttpApi / Web / HttpApi.Client：暴露HTTP接口，包含控制器、Swagger配置、API层适配器，以及客户端生成的调用包装类。

• Migrations / Migrator：数据库迁移工具或独立的迁移项目，负责数据库版本管理与结构更新。

• Tests：该模块的单元测试、集成测试工程，包含各类测试用例与测试数据。

• Module 类：如 YiFrameworkRbacApplicationModule，通常位于 Application 项目中（或各层均有），负责服务注册（ConfigureServices）、应用初始化（OnApplicationInitialization），以及容器/管道的依赖声明。

四、项目引用与依赖关系约定

为保证分层架构的合理性与解耦效果，项目间引用需遵循以下约定：

1. Application 层引用 Application.Contracts 层（实现契约）和 Domain 层（调用领域服务）；

2. Application.Contracts 层仅被上层（Web、客户端、其他模块）消费，不引用任何实现层；

3. Domain 层仅引用 Domain.Shared 层（及少量基础库），不依赖任何持久化或基础设施实现；

4. SqlSugarCore 层引用 Domain 层（实现其定义的仓储接口）；

5. 最终将各模块项目添加至解决方案，可通过命令行dotnet sln add或 Visual Studio 的 Solution Explorer 手动添加。