domain层绝不能引用microsoft.entityframeworkcore，必须仅依赖net6.0或netstandard2.1；所有ef core相关实现（dbcontext、配置、迁移等）严格限定在infrastructure层，通过接口注入仓储，确保领域模型可移植、规则内聚、事件自动触发。
Microsoft.EntityFrameworkCore，这是C#项目落地DDD最硬的边界。跨不过去，所谓“分层”只是给三层架构套了个DDD名词外壳。
Domain层为什么连[Table]都不能加
一旦在 Order 类上加 [Table("Orders")]，或让实体实现 IEntityTypeConfiguration<order></order>，Domain项目就和EF Core强绑定。这不是“写法不优雅”的问题，而是直接破坏了领域模型的可移植性：
- 换数据库（比如切到
CosmosClient）时，得重写所有实体类，因为注解/配置是EF专属语义 - 想引入事件溯源，发现
AggregateRoot的生命周期已被DbContext的变更追踪逻辑污染 - 单元测试里根本 mock 不了
Order——它的构造函数悄悄 new 了DbContext或依赖了 EF 的内部状态
正确做法：Domain层只依赖 net6.0 或 netstandard2.1，所有数据映射、连接字符串、迁移命令全扔进 Infrastructure 层。
IOrderRepository 返回 IQueryable<order></order> 是典型越界
这个接口签名看似方便，实则把EF的查询构建器泄露到了应用层：
- 业务规则会散落在控制器或应用服务里，比如
.Where(o => o.Status == "Confirmed")写在API层，违反“规则封装在领域内”原则 -
IQueryable延迟执行 + 表达式树解析，导致SQL生成不可控，N+1、未索引字段过滤等性能陷阱难以收敛 - 无法对查询做统一审计、缓存或租户隔离——这些都该是基础设施职责，不是领域该操心的事
替代方案只有两个务实选择：
- 用
Specification<order></order>封装意图，比如repo.Find(new ConfirmedOrdersInLastWeekSpec())，让查询条件本身成为可测试、可复用的领域概念 - 按真实用例拆接口：
IOrderQueryService.GetConfirmedByCustomer(string customerId)，返回IReadOnlyList<order></order>，明确边界与语义
应用服务里写 if (order.Total > 1000) 就等于没做DDD
ApplicationService 不是业务逻辑容器，它只干三件事：取数据 → 调领域对象 → 存结果。所有判断、转换、校验必须收在 Order 自身方法里，例如：
public void Confirm()
{
if (_status != OrderStatus.Draft) throw new DomainException("Only draft orders can be confirmed");
if (_total > 1000 && !_customer.IsVip) throw new DomainException("Non-VIP orders over 1000 require manual review");
_status = OrderStatus.Confirmed;
AddDomainEvent(new OrderConfirmedEvent(Id));
}
这样做的关键好处：
- 业务规则集中、可测试、不可绕过——没人能绕过
Confirm()直接改_status - 领域事件自动触发，比如发通知、更新库存，不用在应用服务里手动
eventBus.Publish(...) - 值对象（如
Money、OrderId）能天然防御无效状态，比如new Money(-100)可直接抛异常
Infrastructure层才是EF Core该待的地方
所有 DbContext、DbSet<t></t>、OnModelCreating 配置、迁移脚本、连接工厂，必须严格限定在 Infrastructure 层。这里可以也应当用到EF的全部能力：
- 用
ValueConverter映射JsonString到Address值对象 - 用
OwnsOne配置嵌套结构，但不暴露给Domain层 - 仓储实现类里调用
_context.Orders.AsNoTracking().ToList()，但接口定义仍是IReadOnlyList<order></order>
最容易被忽略的一点：Infrastructure层向Domain层提供实现时，必须通过构造函数注入 IOrderRepository 接口，而非直接传 DbContext。否则，应用服务就能拿到 DbContext 并自行 .Add()，彻底绕过领域规则。
