Domain Driven Design, SOC, and entity identification

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.