分离领域模型和持久性模型时，变更跟踪是如何成为问题的？

Question

我在这里阅读了这个问题：Having Separate Domain Model and Persistence Model in DDD

并专门看这段代码：

public class ApplicationService
{
    private ITicketsRepository ticketsRepository;

    public ApplicationService(ITicketsRepository ticketsRepository)
    {
        this.ticketsRepository = ticketsRepository;
    }

    public bool IsTicketExpired(int ticketId)
    {
        Ticket persistanceModel = this.ticketsRepository.GetById(ticketId);
        TicketEntity domainModel = new TicketEntity(
            persistanceModel.Id,
            persistanceModel.Cost,
            persistanceModel.ExpiryDate);

        return domainModel.IsTicketExpired();
    }
}

此代码表示存在单独的域模型和持久性模型。我试图了解使用这种方法的局限性是什么。在整个互联网上，我读到了使用 NHibernate 时更改跟踪是一个问题，但我不明白为什么。更改跟踪是在域模型映射回持久性模型之后处理的。变更跟踪如何成为问题？更改跟踪如何成为问题的一个实际示例将对我有所帮助。

更新 请看下面的代码：

//Repository
public Ticket GetTicket(int ticketId)
{
    return this.ticketsRepository.GetById(ticketId);
}

我在应用程序服务中这样做：

//Application Service
Ticket ticket = applicationService.GetTicket(1);
ticket.Cost = .....
TicketEntity ticketEntity = AutoMapper.Map<TicketEntity>(ticket);
ticketEntity.DomainMethod();
ticket = AutoMapper.Map<Ticket>(ticketEntity);

Q1) ORM 的好处是否在此代码中丢失了，例如变更跟踪？请注意，持久性对象是从存储库返回的，然后映射到域对象，然后又回到同一个持久性对象。

Q2) NHibernate 如何跟踪更改，即它如何知道 Ticket(persistence object) 是数据库中的票据 1。我想这不仅仅是ID。

Answer 1

更改跟踪没有问题。领域与持久性的融合是。 “域模型”主要是一些易于映射到表的数据结构。在许多领域中，您可能会处理 99% 的数据结构并附加一些规则。在这些情况下，您的域模型看起来与持久性模型几乎相同。

但在更抽象的层面上，领域模型主要建模业务行为，状态（数据）只是一个工件。此外，它从业务角度（功能）看待事物。

持久性模型是关于存储状态，即以易于检索的方式结构化的数据。对于涉及许多概念及其特定模型和用例特定业务规则的复杂功能域，生成的模型与持久状态有很大不同。

ORM如何跟踪变化只是一个实现细节，与DDD无关，但是如果领域足够丰富，那么简单的CRUD解决方案，尤其是领域模型的心态 = state+behaviour aka classes 成为一个障碍。有或没有 ORM。

对于 Domain = 98% Persistence Models 的应用，没有问题，你可以使用任何你想要的 ORM。

Answer 2

@MikeSW 回答的大部分细节都是正确的；我只不同意变更跟踪。我的答案更多是关于 NHibernate 而不是 DDD。

是的，更改跟踪将是一个问题，但这取决于ISession 的管理方式。此外，不仅更改跟踪，它还会影响 NHibernate 的其他功能，如会话级缓存、延迟加载等。

让我们假设ISession 在请求级别进行管理，即每个请求一个ISession。下面提到的所有活动都是一个请求的一部分。

public TicketEntity GetTicket(int ticketId)
{
    Ticket persistanceModel = this.ticketsRepository.GetById(ticketId);
    TicketEntity domainModel = new TicketEntity(
        persistanceModel.Id,
        persistanceModel.Cost,
        persistanceModel.ExpiryDate);

    return domainModel;
}

public void SaveTicket(TicketEntity ticketEntity)
{
    Ticket ticket = //Here, you have to map TicketEntity to Ticket
    this.ticketsRepository.Save(ticket);
}

现在，以下是同一请求中应用程序某处的代码：

TicketEntity ticketEntity = applicationService.GetTicket(1);
ticketEntity.Cost = .....
.....
.....
applicationService.SaveTicket(ticketEntity);

NHibernate 有能力跟踪Ticket 中发生的变化，但这种能力在这里没有用。从GetTicket 返回时Ticket 丢失，在SaveTicket 时创建新的Ticket。即使ISession 处于请求级别并且能够看到发生的更改，NHibernate 的更改跟踪功能也根本没有使用。

以下代码（绕过域模型）将正确跟踪更改：

public Ticket GetTicket(int ticketId)
{
    return this.ticketsRepository.GetById(ticketId);
}

以下是获取和修改Ticket的方法：

Ticket ticket = applicationService.GetTicket(1);
ticket.Cost = .....
.....
.....

现在，你不要打电话给SaveTicket；取而代之的是 Flush ISession 在应用程序中检测到 EndOfRequest 的位置。

在这种情况下，NHibernate 的更改跟踪会跟踪对 Ticket 所做的更改并自动刷新这些更改。

通过将持久性模型翻译到域模型，我们绕过了 NHibernate 的这种能力，因为持久性模型永远不会改变。

每种方法都有优点和缺点。参考this问题。

编辑：（用于您的更新）

Q1)：如果相同的持久性模型实例被修改并且对相同的ISession 可见，则新代码将受益于更改跟踪。在这种情况下，它还将利用会话级缓存。在使用 AutoMapper 进行映射时，NHibernate 将加载引用的实体（如果可能不需要）。不过，这取决于每个用例。

Q2）：实际上，这应该是一个不同的问题，过于宽泛，无法在此答案中回答。无论如何，请参考this。

Answer 3

顺便说一句，我不建议将域模型类与持久性对象分开。

您可能想看看 Vaughn Vernon 为他在 DOT.NET 上的应用程序做了什么

他是著名的《实施领域驱动设计》(IDDD) 一书的作者。我向所有认真对待 DDD 的开发者推荐的必读。

https://github.com/VaughnVernon/IDDD_Samples_NET/tree/master/iddd_identityaccess/Domain.Model/Identity