In DDD, concurrency belongs to application layer?

Question

In DDD, the model has to implement only the bussiness logic, and it has not the responsability about another things, like persistance.

So I was thinking that perhaps is in the application layer a good place, because it is the layer who get data from the database with the repository, call the methods of the domain and persists the data. Something like that:

class MyApplicationService
{
    public void UpdateEntity()
    {
        long myActualVersion = Repository.GetActualVersion(EntityToUpdate.Id);
        EntityToUpdate.Update(data);
        Repository.IncrementVersion(EntityToUpdate.Id);
        //Do something to check if it will be update the expected version or not.
        Repository.Commit();
    }
}

But I was thinking that perhaps it belongs to the repository, something like that:

class Repository
{
    Update(paramEntityId, paramNewData)
    {
        ActualEntity = _conntext.Get(paramEntityId);
        ActualEntity.Update(paramNewData);
        _context.Commit();
    }
}

In this case, in the database I could have a row version and it will throw an exception that could be handle in the application layer and decide if retry or not, for example.

I am thinking that perhaps the second option it is better, because concurrency is a database concern, so perhaps it is better to handle in the repository, but I am not sure if perhaps it is better in the application layer, or there are another options.

Thanks.

Answer 1

The reference you should review is the original domain driven design book (Evans 2003). Chapter 6 describes life cycle management patterns (aggregates, factories, repositories).

Leave transaction control to the client. Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything.

Vaughn Vernon's 2013 book (Chapter 12) offers similar advice; transactions are managed in the application layer.

If you imagine that the application layer is managing a unit of work, then it makes sense that transaction management would be outside the repositories, since they should not know what other resources are also participating in the current transaction.