Domain-Driven Design – Unique Value Object vs Entity

domain-driven-designentityvalue-object

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:

Does a collection of configuration parameters sounds like a value object?
Am I mixing the concept of uniqueness of AdvertisementEvent within Movie and transactional integrity rule?
Does any of the choices in point (2) implies that AdvertisementEvent must be a member of the aggregate made by Movie?
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)
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

Best Answer

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).

Related Solutions

DDD and Value Objects. Are mutable Value Objects a good candidate for Non Aggr. Root Entity

Everything that has an identity should be an Entity, and everything that does not have an identity is a simple value, hence a value object.

To quote Martin Fowler (which in turn qoutes Eric Evans)

Entity: Objects that have a distinct identity that runs through time and different representations. You also hear these called "reference objects".
Value Object: Objects that matter only has the combination of their attributes.

Reason to make your address a Value Object:

If your address is mutable, you will likely screw up your mailing history in the end. For example, if you're shipping items to an customer, you can't be sure to which address you actually shipped something in the past if the address your MailingHistory table is referring to has been changed.

The MailingHistory entry We shipped A764 to address 657 could mean We shipped article A764 to Boston yesterday and We shipped article A764 to New York tomorrow.

If the mailing address has to been changed, there's no need to delete the old one. Keep it, and mark it as inactive, and the new one as active.

Of course you could treat your address as a Entity, but only when updating it would not change the actual place the address is referring to, hence only allowing the correction of typos.

If you're sure you could ensure that, than using an Entity would be possible.

But the best solution IMHO is to not referrence an address Entity in your mailing history, but rather save the specific address directly in your mailing history table (basically copying the data of the address).

This way, you always know where you shipped your stuff (or whatever you are mailing), and since you would use a mutable Entity, your address table won't be cluttered up.

I've worked with/on several ERP systems, and nearly all of them used this approach.

You will have some redundancy in your database, but it's the most pragmatic way IMHO.

DDD – How to Refer to Value Object Inside Aggregate

Depending on the collaborative degree of your application, you might find yourself in trouble if 2 or more users try to increment the same Choice concurrently. That will happen whether it's a VO or an Entity in the same Aggregate as the Poll.

To me the natural consistency boundary implied by the domain action of voting includes the user. So I would suggest a full fledged PollChoice Aggregate Root with a link to the User, or if there are multiple choices per poll, a PollResponse AR containing all choices (which can then be VO's) made by a particular user to a specific poll.

Edit : something along these lines

class PollResponse {

  int pollId;
  int userId;
  Choice choice;
  Datetime dateResponded;
}

Best Answer

Related Solutions

DDD and Value Objects. Are mutable Value Objects a good candidate for Non Aggr. Root Entity

DDD – How to Refer to Value Object Inside Aggregate

Related Topic