不使用AutoMapper，在构造函数中映射实体是否符合DDD？求更佳方案

这种做法存在DDD原则上的问题，核心问题在于分层耦合和职责偏离：

1. 数据库实体 → 领域实体：反向依赖问题 #

领域层是DDD的核心，理应只聚焦业务规则，不依赖任何外层模块（比如数据访问层的DB实体）。如果领域实体的构造函数接收DB实体作为参数，等于让领域层直接依赖了数据访问层的类型，违反了依赖倒置原则（高层模块不应依赖低层模块，二者都该依赖抽象），同时破坏了领域层的独立性——日后DB实体结构变化，你得修改领域实体的构造函数，完全没必要。

2. 领域实体 → 视图实体：职责越界问题 #

视图实体（DTO）的核心职责是作为表现层的数据载体，不该承担映射逻辑。把映射放在它的构造函数里，会让视图实体变成既存数据又做转换的“多面手”，违反单一职责原则。而且如果后续视图结构变化，或者需要不同的视图格式，你得不断修改这个构造函数，维护成本会越来越高。

不用AutoMapper完全没问题，但要把映射逻辑从实体构造函数中抽离，放到专门的组件里：

方案1：数据库实体转领域实体 → 用领域工厂 #

在基础设施层（依赖领域层和数据访问层的层级）创建专门的工厂类，负责从DB实体生成领域实体。这样既隔离了领域层和数据访问层的依赖，又把映射逻辑集中管理。

示例代码：

// 领域层的纯领域实体
public class Product
{
    public Guid Id { get; private set; }
    public string Name { get; private set; }
    public decimal Price { get; private set; }

    // 领域实体构造函数只聚焦业务规则，不依赖DB实体
    private Product(Guid id, string name, decimal price)
    {
        Id = id;
        Name = !string.IsNullOrEmpty(name) ? name : throw new ArgumentException("产品名称不能为空");
        Price = price > 0 ? price : throw new ArgumentException("产品价格必须大于0");
    }

    // 提供静态工厂方法供外部创建实体
    public static Product Create(Guid id, string name, decimal price)
    {
        return new Product(id, name, price);
    }
}

// 基础设施层的工厂类，负责DB实体到领域实体的转换
public class ProductDomainFactory
{
    public Product CreateFromDbEntity(ProductDbEntity dbEntity)
    {
        return Product.Create(
            dbEntity.Id,
            dbEntity.ProductName,
            dbEntity.UnitPrice
        );
    }
}

方案2：领域实体转视图实体 → 用映射器类 #

在表现层或应用层创建专门的映射器类，负责把领域实体转换成视图实体。映射逻辑集中在一处，视图实体只保持纯数据结构。

示例代码：

// 表现层的纯视图实体
public class ProductView
{
    public Guid Id { get; set; }
    public string ProductName { get; set; }
    public string FormattedPrice { get; set; }
}

// 映射器类，处理领域实体到视图实体的转换
public class ProductViewMapper
{
    public ProductView MapFromDomain(Product domainEntity)
    {
        return new ProductView
        {
            Id = domainEntity.Id,
            ProductName = domainEntity.Name,
            FormattedPrice = $"¥{domainEntity.Price:F2}"
        };
    }
}

• 构造函数映射的方式会导致层间耦合、职责混乱，不符合DDD的分层和单一职责原则。
• 手动映射的最优解是用工厂类处理DB到领域的转换、映射器类处理领域到视图的转换，既保持各层的独立性，又让映射逻辑可维护。

内容的提问来源于stack exchange，提问作者Scrim