Understanding Domain Models - One Concern at a Time

At one point during the Domain-Driven Design book club meeting yesterday, we had confusion about distinguishing between Entities and Value Objects.

For example, database persistence of both Entities and Value Objects can be done in the same way, sometimes even using an ID column for Value Objects (even if that was unnecessary.) Moreover, caching can be done for Entities too, which seemed to further decrease the distinction between Entities and Value Objects.

I had to interrupt the talk for a second and emphasize my preference to first understand the essence of Entities and Value Objects independently of Persistence. The architect thought it would also help to take Caching out of the equation. Afterwards, our discussion got to the heart of the matter without the peripheral concerns, and we were able to descern the true domain-level differences between Entities and Value Objects.

The point of this is when thinking about the domain model, it is easier to understand how it fits with the business by leaving other (usually technological) concerns out of the equation, at least temporarily. Once there is a good understanding of how the domain model fits the business (e.g. agreeing that States will be treated as Value Objects or Customers will be treated as Entities), each of the other concerns can be focused on and addressed separately (e.g. persistence, caching, etc...)