Please be aware, that DDD only mandates that the domain layer invocations operate on the aggregate root level. Is does not mandate the same for the persistence layer invocations. That’s out of scope. That’s why I would go for the following approach assuming that you have an "OrderAggregateDomainService" with a method renameOrderItem(orderId, orderItemId, newOrderItemName). The method would basically perform the following 3 steps:

1. Load the whole Order domain object via the “OrderRepository.retrieveOrderById(orderId)” call.

2. Invoke Order.renameOrderItem(orderItemId, newOrderItemName) => I assume there is some business logic required that checks the validity of the “newOrderItemName” and that we want to implement that logic in the domain type.

3. If the validity check is ok, then invoke a second repository method “OrderRepository.renameOrderItem(orderId, orderItem : OrderItem)” => This method does not load the whole order again, it only doublechecks if the persisted OrderItem actually refers to the given orderId and then performs the update of the OrderItem

Additional Remarks:

If someone else would try to rename the same OrderItem at the same time then we could actually face a race condition. Let’s assume both try to update from the same version 1. There are two cases: If you map the version attribute from the JPA entity also to the domain entity and vice versa, then the slower one should get the classical OptimisticLockException. If you do NOT map the version attribute to the domain entity and back, then things get too complicated to explain all variations in detail here, but the bottom line is that you should in fact map the version attribute to the domain entity.