如何在工作单元中处理数据库生成的ID值

Question

Caveat I am using SQL Server 2008 R2 as the persistence framework. I do not have the option of changing this. I am using a Micro-ORM for persistence. I also do not have the option of changing this. Thirdly, I do not have the option of changing the table identity columns to guids. They have to remain as integers.

The aggregate I want to create is a project that has a few tasks. I want to persist this to two tables, one with the parent project and the other with the tasks, linked by the parent project id. Simple enough. Obviously the table structure is a persistence detail that I would like to keep out of the domain model. Once I persist this, I want to send the project's id back to the user so that they may navigate to the newly created project.

public class CreateNewProjectRequest
{
    public int InterestingInteger { get; set; }
    public string MoreDataNeededForRequest { get; set; }
}

public CreateProjectApplicationService
{
    private readonly IUnitOfWork uow;

    public CreateProjectApplicationService(IUnitOfWork uow)
    {
        this.uow = uow;
    }

    public int CreateNewProject(CreateNewProjectRequest request)
    {
        var project = ProjectAggregate.CreateFrom(request);
        var projectRepository = new ProjectRepository(uow);
        projectRepository.Add(project);
        projectRepository.Save(project);
        //db transaction commits
        uow.Commit();
    }
}

Referencing several resources on this topic (Vaughn Vernon's DDD book and the latest Wrox DDD book Patterns, Principles, and Practices Of Domain-Driven Design), I see that the repository is responsible for persistence of the aggregate root. The repository interface lives in the domain model.

In the Wrox DDD book, a UnitOfWork and a IUnitOfWorkRepository exist and are defined as follows:

public interface IUnitOfWork
{
    void RegisterAmended(IAggregateDataModel entity, IUnitOfWorkRepository unitofWorkRepository);
    void RegisterNew(IAggregateDataModel entity, IUnitOfWorkRepository unitofWorkRepository);
    void Commit();
    void Clear();
}

public interface IUnitOfWorkRepository
{
    void PersistCreationOf(IAggregateDataModel entity);
    void PersistUpdateOf(IAggregateDataModel entity);
    void PersistDeleteOf(IAggregateDataModel entity);
}

public class ProjectRepository : IProjectRepository, IUnitOfWorkRepository
{
    //Simplified for example's sake, I didn't implement all of IUnitOfWorkRepository
    private readonly IUnitOfWork uow;

    public ProjectRepository(IUnitOfWork uow)
    {
        this.uow = uow;
    }

    public void Add(Project project)
    {
        unitOfWork.RegisterNew(project, this);
    }

    public void PersistCreationOf(IAggregateDataModel entity)
    {
        //Persist changes via micro ORM -- new id is available
    }
}

The implementation for commit created a transaction and persists it.

The issue I am having is that when the Commit() method is called to persist the transaction to the data store, I have a new ID that was created in the process. I understand that CreateProjectApplicationService might touch multiple aggregates (in my case it does not... yet), so the unit of work implementation manages the transaction here so the data store is in a consistent state.

I can't simply just seed the id from the database. I want to use scope_identity() to get the id that the db generated because it is an autoincrementing column.

What might be the cleanest way to achieve getting this newly inserted id? Or, is the unit of work an inappropriate abstraction here and should be left to other use cases?

Answer 1

In DDD the unit of work is the business process itself. What you have there is a popular anti-pattern. Anyway, considering your constraints the cleanest thing to do is to make the Id property assignable and set it inside the repository.

So your project will get the id inside the repository.Add method. About adding tasks, that should be a different operation, you are trying to do too much in one operation. Basically, you're using the 'old' transact script (CRUD) approach but with DDD terms.

Normally, you should have one operation for add project -> ProjectCreated[event] -> AddDefaultTasks.

The UI also should be more task based instead of doing 2 different things at once.

I'd say, you can't really do proper DDD when the db is in charge of generating ids. The point is, DDD is not patching crappy codebase with a magic recipe, it's about doing proper design top-down. But you are in charge of patching now, so you can't actually do DDD.