Trying to convert some entities into value objects I am stuck in a case where what seems a value object must be unique within an aggregate.

Suppose we have a Movie entity which makes the root of an aggregate. This Movie entity is related with some set of AdvertisementEvent objects with the role of displaying an advertisement at certain timestamp.

The AdvertisementEvent contains a link to some Banner that must be displayed, the coordinates and some effect filters.

Since AdvertisementEvent is just a collection of configuration parameters I am not sure if I should care about its identity and treat it like just a large value object. However I do care that within a Movie there must be only one AdvertisementEvent at a certain timestamp, probably even around the timestamps.

I find hard to split my doubts in multiple independent questions, so there they go:

  1. Does a collection of configuration parameters sounds like a value object?
  2. Am I mixing the concept of uniqueness of AdvertisementEvent within Movie and transactional integrity rule?
  3. Does any of the choices in point (2) implies that AdvertisementEvent must be a member of the aggregate made by Movie?
  4. Is my AdvertisementEvent object an Entity, a Value Object or an Event Object? (I used the Event suffix in the name to highlight my confusion)
  5. Are large value objects like this a design smell?

I guess that I am not dealing with an Event in the sense of DDD because it is not something that just happens. The real DDD event should be something more like AdvertisementEventReached

1 Answer 1


The distinction between Entity and Value object should be based around the question: If I have two objects with the same contents (two AdvertisementEvents linking to the same Banner with the same parameters), should I treat them differently or can one be replaced by the other without affecting how the software works?

In this case, I would say that you can replace one AdvertisementEvent by another with the same values without affecting the operation of the software. This makes them Value objects (the contained value is what counts, not the identity of the object itself).

As for the size of a Value object: As long as it contains a coherent set of parameters for a single responsibility, there is no limit on how large a Value object can be. In the implementation it might be good to pay special attention to large value objects to ensure they are not needlessly and excessively copied but otherwise it is no problem.

As for the constraints on the number of AdvertisementEvents you have within a Movie, this is a constraint on the relation between a Movie and its collection of AdvertisementEvents, not on one of those classes individually. As such, the most logical place to enforce the constrained is at the point where the collection gets maintained in Movie (thus in the method where you try to add an AdvertisementEvent).

  • Thanks so much! Despite reading so many times about asking that question to differentiate Entities from Value Objects, this time it has finally "clicked". I guess I needed a problem in my real life to learn that lesson. I love my problem because it exposed en Event Object (which is not a Domain Event) and what seems to be uniqueness (which is an invariant). I guess that in my question I should have said "invariant" instead of "transactional integrity rule". Commented May 3, 2013 at 15:16
  • Interesting... as a side effect of understanding better this difference, now I can clearly see the importance of stateless/inmutable value objects in order to improve my programs stability. I guess I was thinking too much about GUI implementation details... easy mutation is nice in the Application Layer, but in the Domain Layer I do want the AdvertisementEvent to be inmutable! Commented May 3, 2013 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.