Would you consider an email address to be an entity in this example?

[Jack Snow]

In this domain, there is the concept of a User which is an entity.

An entity can have multiple (unlimited) email addresses associated with his account, with 1 email address being chosen as his primary address.

I have considered modelling the email addresses as value objects:

{

   "email": "na...@company.com",

   "primary": true

}

However, the user needs to be able to remove email addresses from the UI or change the primary email address to a different one. In order to do so, he would need the id of the email address.

In such a case, is it a valid reason to make the email address an entity? Also, what do you guys think about storing the whether the email address is the primary one as part of the value object? user.addEmail(newEmail) would enforce the invariant that there can only be one primary email address.

[Kijana Woodard]

An email address is an identifier.

---

From: Jack Snow
Sent: ‎11/‎15/‎2015 2:36 AM
To: DDD/CQRS
Subject: [DDD/CQRS] Would you consider an email address to be an entity inthis example?

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin Yates]

I think email address is a value object - it’s identity doesn’t change and it doesn’t really need an id. As such, the data structure I might use would be something like:

 

{“primary”: “abc@def” “others”: [“something-else@efg”]}

Because they are value objects their reference _is_ the value. The identifier of “abc@def” _is_ “abc@def” :-).

HTH

 

[Jack Snow]

Thanks Kijana and Colin!

That certainly clears things up for me.

How about these 2 scenarios:

1. Each user within the system can associate unlimited email addresses with their account and select 1 as the primary email address. However, all email addresses within the system must be unique (no email address can be used by more than 1 user). Does this requirement turn the email address into an entity?

2. How about the if we have a system where there are multiple users, and each user can associate multiple addresses with their account and select 1 as the primary address. Maybe a data structure for each address could look like this:

{

  "line1": "Apartment 1",

  "line2": "50 Some street",

  "city": "New York City",

  "state": "New York",

  "zip": "123456"

  "country": "US",

  "primary": true

}

We want to be able to send a command to set a certain address as the primary address (which will set the primary property of the current primary address to false as well). We also want to be able to delete a specific address. Since the VO is made up of multiple properties, we would need an identifier to reference each address. Does have such an identifier on each address turn it into an entity?

[Colin Yates]

Hi Jack. The only thing that _should_ turn something into an entity is how you define that thing. That isn’t very helpful :-). 

Crudely, ask yourself “if something I know about this thing changed, would it be the same thing” and “if everybody had this thing and one person changed it, should everybody change it”. Entities are valid if the answer to both of those questions is ‘yes’.

Typically value objects are colours, numbers, addresses (or at least parts of addresses).

An example, if my shirt is red and I dye it to be blue then have I changed the _colour_ red or have I simply chosen a different colour? Obviously I have chosen a different colour; my socks that were red are still red, i.e. I haven’t changed _red_, red is still red. But note it is the same shirt. The colour is a value object, the shirt is an entity, because its identity is the same over time but its value isn’t.

Now for the other complicating factor…

Imagine I run a warehouse where I sell shirts - when you order 30 red shirts from me do I really care _which_ red shirts they are? Do I find it useful to identify each shirt? No, of course not. In this case the shirt is a value object.

In general, people err on making too many entities. I generally recommend everything is a value object until you can justify the benefit of distinguishing different instances of the same thing.

As ever, it depends on what is useful for the business.

So no, email addresses are still value objects. For the uniqueness I tend to be pragmatic and stick a unique index in the DB and let the error propagate up; it isn't that likely to happen and the user can always try again if it does (better things for the business to spend my coding time on). For the addresses, there is no technical reason why you can’t just send through the value object to be deleted. However, if you wanted to name them then sure, why not. “home address’ or even “address 1”, “address 2” etc. But the address is still technically a value object :-). What’s the difference between a value object with an identity and an entity? Nothing that can be expressed in code but a whole bunch of things from a modelling perspective.

[Jack Snow]

Hey Colin,

That was extremely useful. I think the problem for me is that I always assumed that only entities can have ids. It is now all clear to me now! :)