Take the 2-minute tour ×

I've been trying to wrap my mind around DDD and how it can relate to MVC, but I'm having trouble with regards to entity identification.

In particular, I'm trying to maintain strict separation between my presentation, domain, and data models. My hangup here is in how I preserve entity identification across these boundaries. To clarify, I'm using separate classes to represent the same entity in different contexts - for example, I have a 'ShipmentRequest' domain class, several 'ShipmentRequestView' presentation classes (depending on the properties required by a particular view), and a 'shipment_request' database table (my data model).

I feel like using an 'ID' property (like ShipmentRequestId) would be a violation of the separation I'm trying to achieve, since this ID property is a database concern, and not a domain concern; and I don't want to pass the same object between layers, as this would mean passing unneeded data into my presentation layer.

How do I preserve this separation, and yet track identity between these layers?

share|improve this question

3 Answers 3

up vote 2 down vote accepted

Without the Id field in your entity you cannot map it to a database row. Therefore this id field even though it has nothing to do with your entities must leak into your domain model.

I feel it is most often overkill to use a presentation model, especially if what your are trying to achieve is hide some properties.

I think separation of concerns is mostly driven by the bounded context. For example, your Person, PersonView and Person table all seem the relate to a transaction processing context. In such a context I would make not even have a PersonView and the person table would be abstracted away.

On the other hand if you are in a reporting context, a PersonView would be more useful.

I think that the context is much more important than any layering scheme.

As for the lack of a natural key in your person entity, it could mean that Person is not really an entity. For exemple, in any real life application, there is always a number associated with the person: an employee has a employee number, a client as an account number, etc. This business id is definitely part of the domain.

share|improve this answer
If a Person is not an entity, what is it? It can't be a value object - more than one physical person can have the same name and other stats. Regardless I use Person as an example, not representative of the domain I'm actually working against. –  Erik Forbes Feb 5 '09 at 22:39
That said, your point about context is an important one. Thank you. =) –  Erik Forbes Feb 5 '09 at 22:40
Person is often used as standard example that people use but I think it is a bad example because there is not context. –  Simon Laroche Feb 5 '09 at 22:52
Lets say I'm doing some demographics analysis and I don't care about the id of any particular person, I just care about its attributes. Could Person be a value object in this context? –  Simon Laroche Feb 5 '09 at 22:56
I suppose it depends on the attributes in question. In that context, I would say so. Good point about the example - maybe I'll refactor my question with a better one. –  Erik Forbes Feb 5 '09 at 23:20

I think having an "ID" field on entities is a concession a lot (most?) people end up making, and I wouldn't feel guilty for doing so.

As you say, even when you're not dealing with the database, you still need some notion of identity. You can try to come up with some kind of "natural" identity for each entity (a field like name, or a combination of several fields), but this isn't always possible. Even when it is, having an ID field often acts as a handy shortform for saying "the entity whose name is X, and whose date of birth is Y, and whose SSN is Z".

In the end, while arguably less "pure", having an ID field will likely simplify things a great deal.

share|improve this answer
This is probably, in the end, what I'll end up having to do. Thanks for the answer. =) –  Erik Forbes Feb 5 '09 at 22:17

Shipment Request is definitely a better example!

How will the users find a shipment request? Depending on the answer you might need an id that users might remember, for example 20091012-A.

Can a shipment request id ever change? If no, use the db key for identity.

Will you need to transfer shipment requests from one system to another? If yes, do not use the db key for identity.

Whatever key you use you will need to make it available in the presentation model so that you can build links to actions on a particular shipment request.

share|improve this answer
Users find SRs through a search mechanism, or by listing the SRs belonging to a customer, etc. The IDs can be used (in emails for example) to point out specific SRs, but SRs are never consumed by other systems. I guess DB key is the way to go for this. –  Erik Forbes Feb 6 '09 at 0:26

Your Answer


