ASP.NET 中的 DDD：30 个聚合后的可扩展性问题

ASP.NET中DDD扩展难题：突破30个聚合体的瓶颈

当一个项目在ASP.NET中使用Entity Framework Core时，聚合体数量超过30个，‘一条查询对应一个聚合体’的原则就会引发严重的性能问题。每个聚合体都需要完整加载嵌套对象，导致生成包含大量JOIN操作的SQL语句。这种情况在ERP系统或电商平台中尤为突出，对象图的嵌套深度可达5到6层。

典型的订单聚合查询如下所示：

var orders = await context.Orders
    .Include(o => o.Customer)
        .ThenInclude(c => c.Address)
    .Include(o => o.Customer)
        .ThenInclude(c => c.Contacts)
    .Include(o => o.Items)
        .ThenInclude(i => i.Product)
            .ThenInclude(p => p.Category)
    .Include(o => o.Items)
        .ThenInclude(i => i.Discount)
    .ToListAsync();

生成的SQL语句包含数十个LEFT JOIN，执行效率显著下降。即使仅更新订单头信息中的一个字段，也必须加载全部订单项作为聚合体的一部分，进一步加重性能负担。

规范模式的指数级增长及其局限性

规范（Specification）模式用于封装查询逻辑，但当聚合体超过30个时，规范类的数量可能飙升至数百个文件。通过And/Or组合方式构建查询，由于EF Core对IQueryable的依赖，会导致生成低效的SQL。

主要挑战包括：

• ORM绑定性强：规范无法直接用于Dapper或gRPC，需重写代码。
• 组合复杂度高：涉及角色、状态和时区等真实业务场景时，逻辑难以维护。
• 抽象开销大：开发者花费大量时间在抽象设计上，远超实际业务逻辑实现。

跨聚合事务与基础设施的沉重负担

在ASP.NET Core中，作用域内的DbContext适用于小型项目的单元工作模式。但在大型系统中，业务流程常需同时更新5个以上的聚合体：下单、支付处理、库存预留、呼叫中心任务创建等。

现有解决方案违背了DDD原则：

• 单数据库事务 —— 导致“上帝服务”出现，破坏聚合边界。
• 分布式Saga或出站消息模式 —— 复杂度提升多达10倍。

结果是，70%的代码量沦为同步协调的基础设施胶水，而非核心业务逻辑。

代码导航：千文件结构与开发迭代变慢

DDD的分层架构（API/Application/Domain/Infrastructure + Features）在拥有30多个聚合体时，可产生超过1,000个文件。修改单一实体字段将影响以下环节：

• 领域实体
• Fluent API配置
• 迁移文件
• 命令类
• 校验器（FluentValidation）
• 处理器
• DTO
• 映射器（AutoMapper）
• 规范类
• 测试用例

这极大拖慢开发速度，增加新人上手难度，并严重影响长期维护。

最关键的五个痛点

• 性能：频繁使用Include/ThenInclude生成低效SQL，API响应时间呈指数级增长。
• 规范模式：无法扩展，绑定EF Core，组合逻辑易出错。
• 事务管理：跨聚合操作迫使开发者在DDD理想与现实业务需求间妥协。
• 代码规模：超过1,000个文件使迭代效率下降50%–70%。
• 混合架构：仅在核心领域应用DDD，外围模块采用CQRS与垂直切片设计更高效。

迁移建议：迈向混合架构

对于聚合体超过30个的项目，推荐采用混合架构方案：

• CQRS：命令与查询分离，读模型无需Include，性能更优。
• 垂直切片：按功能组织代码，减少层级依赖，降低复杂度。
• 特征切片设计：实现模块化，避免僵化的洋葱式架构。

这些方法在保持复杂领域内DDD原则的同时，大幅简化其他部分的开发与维护。

— Editorial Team