Can an Aggregate Root change the 'root' of an Entity?

Question

I have some doubts with Agreggate Roots and working with Entities.

Imagine we have a Box object, which contains Potatoes. In this case and in a DDD point of view, the Aggregate Root would be the Box object, so in case we want to add Potatoes to the Box, we have to do it through the box object.

Now, imagine we have to change one specific Potato to another Box. This is, we have Box A (with Potato A) and Box B. We want move the Potato A to Box B.

My first idea is to create a method inside the Box object, that changes the 'Potato' root (because we can't do it from the Potato itself). All the logic is in the root object, so seems Ok for me.

Is it a good approach to do it this way? Or in case two aggregates roots (of the same type) are involved, we have to create a Service instead?

Some code

public class Box {
 private List<Potato> potatoes;
 public void changeBox(Potato potato) {
 potato.getBox().potatoes.remove(potato);
 potato.setBox(this);
 }
 ...
}
public class Potato {
 private Box box;
 protected void setBox(Box box) {
 this.box = box;
 }
 public Box getBox(){
 return box;
 }
 ...
}
// This should do the change of box
Potato potato = oldBox.getTopPotato();
newBox.changeBox(potato);

Thank you!!

• Constantin Galbenu: "Now, imagine we have to change one specific Potato to another Box" - what do you mean?
• jpadilladev: @ConstantinGalbenu I edited my question.
• guillaume31: @jpadilladev with no invariants or logic in these entities, one can't possibly tell which option is better. You might as well not use DDD patterns for all you care.
• Constantin Galbenu: If you have two Aggregates then you must use a Saga/Process manager because you have two separates transactions. See this: stackoverflow.com/a/48651778/2575224
• Constantin Galbenu: @jpadilladev no. In DDD, if you affect 2 aggregates then you must have 2 transactions.

Answer 1

Potato doesn't need to know which box it belongs to. Box itself is responsible for managing its own potatos. You can have a domain service class which can orchestrate the move. This is as good as a bank transaction where you are moving money from one account to another.

 public class Box { 
 private List<Potato> potatoes;
 public void AddPotato(Potato potato) {
 potatoes.Add(potato);
 }
 public Potato GetTopPotato() {
 var potato = potatoes.First();
 potatoes.Remove(potato);
 return potato;
 } 
 }
 public class Potato {
 }
 public class PotatoMovingService {
 // You can have a method with source and destination box as input, but here I am just writing pseudo-code
 ... 
 var boxA = new Box();
 // Fill boxA with some potatos
 var boxB = new Box();
 var potato = boxA.GetTopPotato();
 boxB.AddPotato(potato);
 ...
 }