37 Actions

Model relationships with DDD (or with sense)?@lawpert the Answer (not Choice) I referred to was the one from the above answer. The rule of thumb is to store aggregate as a whole to preserve its consistency. So if your "Answer (aka Choice)" is not an aggregate root you don't store it directly, even if it's an entity.

Oct31

comment

Model relationships with DDD (or with sense)?@lawpert Answer is a value object, it's going to be stored with an aggregate root of its aggregate. You don't store value objects directly, nor do you save entities if they are not roots of their aggregates.

Oct31

comment

DDD: service/repo operations on IDs or instances?Still think you should make it a value object whether it's natural or not. Referencing a domain entity by a number of type long doesn't make sense. What would you answer if I ask what this number is and what validation rules it has? A primary key in the DB, 8 bytes? I don't think so. You'd probably say it's a global unique identifier and it should be a positive number. This sounds more like a domain concept and business logic, so why not model it as a domain object and encapsulating the validation logic. Also read this.

DDD: How to refer/select a value object inside aggregate?@AlexanderLanger I found that part about the wheels. It says "To know which tire is which, the tires must be identified ENTITIES also. But it is very unlikely that we care about the identity of those tires outside of the context of that particular car.". What I proposed, however, was not identifying the Choices but rather differentiating them using aliases (ordinals) while differentiating them using values would be more than sufficient. Nevertheless, in the light of recent clarifications on the intended use, it seems reasonable to model the Choices as entities. Thanks for tipping me off.

DDD: How to refer/select a value object inside aggregate?@AlexanderLanger, I removed the confusing statement. Other than that, I think "local" ID doesn't necessarily make it an entity because it's not a clear identity but just a way to differentiate between different Choices in the aggregate boundary. Think of it as an alias for its value.

DDD: How to refer/select a value object inside aggregate?Right. All depends on how you wish to model it. Besides the fact that value objects don't have clear identity, they also don't have state and life-cycle. So if you want a Choice to have a state and a life-cycle you'd probably consider implementing it as an entity. Use this link as a reference.