Holding/Persisting collection of Value Objects

Question

DDD really began making sense when I stopped thinking about database first (started working with Uuid instead of thinking about auto_incremented ids). Today I realized you can persist value objects, and not just entities. DDD, value objects and ORM

My question concerns the Personality entity. I need to persist 3 representations of MealTime (one for breakfast, lunch, dinner where their respective category is 1, 2 and 3), but most importantly the behavior I'm trying to encapsulate is the CreateWeek in the MealPeriod, it uses the MealTime values to return a weekly structured array.

1. Is the MealPeriod necessary, or should I just have a MealPeriods (or MealTimes) holding the collection of MealTime?
2. If we were to persist the MealPeriod collection, should I add a $_personality_id reference in the class itself or in the repository I'd use the $personality->id() for the personality_id db column name (in the table where we'd save the MealTime collection)?

MealPlan (aggragate root)

final class MealPlan extends AggragateRoot {

    private PlanId $_id;
    private UserId $_user_id;
    private $_personality;

    public function __construct(PlanId $id, UserId $userId){
        $this->_id = $id;
        $this->_user_id = $userId;
    }

    public static function create(string $id, string $userId){
        return new self(new PlanId($id), new UserId($userId));
    }

    public function id(): PlanId {
        return $this->_id;
    }

    // setter/getter for personality
}

final class Personality {

    private PersonalityId $_id;
    private PlanId $_plan_id;
    private Allergen $_allergen;
    private MealPeriods $_meal_periods;

    public function __construct(PersonalityId $id, PlanId $plan_id, Allergen $allergen, MealPeriod $meal_period){
        $this->_id = $id;
        $this->_plan_id = $plan_id;
        $this->_allergen = $allergen;
        $this->_meal_period = $meal_period;
    }

    public static function create(string $id, string $plan_id, int $allergen, array $meal_period){
        return new self(
            new PersonalityId($id),
            new PlanId($plan_id),
            new Allergen($allergen),
            new MealPeriod($meal_period)
        );
    }
}

class MealPeriod {

    private array $_collection;

    public function __construct(array $times){
        foreach($times as $data){
            array_push($this->_collection, $data);
        }
    }

    public function get(int $category){
        return array_filter($this->_collection, function($value) use ($category){
            return $value->category() === $category;
        });
    }

    public function breakfast(): MealTime {
        return $this->get(1);
    }

    public function lunch(): MealTime {
        return $this->get(2);
    }

    public function dinner(): MealTime {
        return $this->get(3);
    }

    public function createWeek(){
        // uses breakfast, lunch and dinner MealTime values to generate some data.
    }
    
}

class MealTime {

    private int $_meal_category;
    private int $_skip;
    private int $_unique;
    private int $_leftover;
    private int $_variety;
    private int $_time;

    public function __construct(int $category, int $skip, int $unique, int $leftover, int $variety){
        $this->_meal_category = $category;
        $this->_skip = $skip;
        $this->_unique = $unique;
        $this->_leftover = $leftover;
        $this->_variety = $variety;
    }

    public function category(): int {
        return $this->_meal_category;
    }

    public function skip(): int {
        return $this->_skip;
    }

    public function unique(): int {
        return $this->_unique;
    }

    public function leftover(): int {
        return $this->_leftover;
    }

    public function variety(): int {
        return $this->_variety;
    }
}

Answer 1

The most critical part of using DDD is the ubiquitous language (UL). I'll come up with a watered-down UL and from there we will be able to answer all of your questions. This simplified excercise should serve to clarify the concept for you and also show my misunderstandings if any.

My question concerns the Personality entity. I need to persist 3 representations of MealTime (one for breakfast, lunch, dinner where their respective category is 1, 2 and 3), but most importantly the behavior I'm trying to encapsulate is the CreateWeek in the MealPeriod, it uses the MealTime values to return a weekly structured array.

Based on this statement your UL could be (an sme defines the UL and it usually contains a lot more detail that this): A User creates a weekly schedule of daily meals. Each day consists of 3 meals; breakfast, lunch and dinner. Each meal is only valid in a set period of the day. Note that all of the details in a UL is customer centric. Forget about the data, the id's or anything technical.

From this UL we can say:

1. CreateWeek doesn't belong in MealPeriod. There's no way to say "a meal period creates a week of meals". It's doesn't fit the UL.
2. There needs to be an initial "noun" (entity) that will be creating schedule. The UL calls that entity the "User".
3. The noun creates the weekly schedule and will therefore contain the Createweek method. The createweek method is a factory method inside the entity. The "User" has now qualified to be called an aggregate root because it is responsible for managing the lifecycle of other entities.
4. The daily/weekly schedule of meals is an entity. The daily schedule entity will contain the 3 meals.
5. Each meal will contain a value-object of 1 period when the meal is valid.

Regarding the serialization: DDD is serialization agnostic. All that's required in DDD is a way to persist entities and models and retrieve the persisted entities and model to their complete state at a later date. This functionality is usually handled outside of the domain but injected into the domain as interfaces.

Having said all that: You don't need to have the "Id" in the meal-period class. The UL describes the meal-period class a value-type (it doesn't make sense outside the context of the "meal"). Value types do not have any identifying ids because they are completely encapsulated by entities.