Where to control optimistic concurrency in a domain-driven design (DDD) application?

I am thinking how to develop an application in a DDD way, and now I am thinking about the concurrency part.

In some examples I have seen that in the domain classes are injected with dependency injection an implementation of the repository, and also in the root aggregate is added a field version, to control the concurrency, so anytime a root method is called, it increases the version.

I don't like this solution so much, first because I don't know if the domain classes know if the data persists or not, so I don't want to inject a repository.

Second, the domain class is responsible for handling the concurrency, I think it is not the best option. For me, the domain classes have to do only the logic of the domain.

So in my case, is in my application layer where I inject the repository, and I work in this way:

class MyApplicationService{    MyApplicationService(IRepository paramOrderRepository)    {        _orderRepository = paramOrderRepository;    }    public void AddItemToOrder(Item paramItem, decimal paramAmount)    {       order myOrder = _çorderRrepository.GetOrder(1);       myOrder.AddItem(paramItem, paramAmount);       _orderRepository.Commit();    }}

The application gets the person to update using the repository, I call the method of the domain class and finally the changes are committed.

But thinking in the concurrency. The concurrency is handled in the root aggregate level, so I have in the Order table in the database a field for the version.

The problem is that here, really I am not modifying the order, I am adding a new item, so no fields in the order is modified, so for the database, there is no concurrency problem.

So I was thinking that perhaps, in the IOrderRepository I could have a method to increase version of an entity, so I could do this:

public void AddItemToOrder(Item paramItem, decimal paramAmount)        {           order myOrder = _çorderRrepository.GetOrder(1);           myOrder.AddItem(paramItem, paramAmount);           _orderRepository.IncreaseVersion(myOrder);           _orderRepository.Commit();        }

But I don't know if it is a good way to handle the concurrency or not. Although I am not very sure how to implement the IncreaseVersion() method of the repository, but but the moment I would focus in this aspect, I am thinking more in the general design, I would think in the implementation later. My intention it is to expose this possible solution.

Sure it would be easier if in domain class I would have a field for the version, so I could do that:

public void AddItemToOrder(Item paramItem, decimal paramAmount)        {           order myOrder = _çorderRrepository.GetOrder(1);           myOrder.AddItem(paramItem, paramAmount);           myOrder.IncreaseVersion();           _orderRepository.Commit();        }

But as I commented, I don't think this is a good idea to have a version property in the domain class, because strictly talking, in the obiquitous language, the experts don't tell anything something like "after add a new item to the order, it is needed to increase the version of the order".

So I don't know if I am wrong thinking that it is not appropriate to have a version property in the domain class, and I don't know if my solution is the best or which options there are to control the concurrency from a DDD point of view. So I would thank any suggestion or alternatives for that.