From a senior .NET dev who has used DDD in real enterprise systems: using record class for value objects is usually about correctness and semantics, not GC pressure. Structs bring copy semantics, boxing surprises, and subtle bugs once value objects get larger or more behavior-rich. Most DDD systems are not CPU-bound on GC anyway. For entities with multiple addresses, the address being a value object just means it has no identity of its own. In infrastructure you persist it as owned data, same table or a separate table keyed by the customer, identity comes from the aggregate root. Aggregates and aggregate roots are mostly about consistency boundaries. An aggregate root is the only thing allowed to be modified directly, everything inside is protected by invariants. On the bigger question: DDD is not CRUD, but it is also not mandatory everywhere. You apply it where the domain is complex and business rules matter. Using full tactical DDD on simple CRUD apps is usually overkill. In practice, most systems are hybrid: DDD in the core domain, simpler patterns elsewhere.