Domain Entity (DE)

Architecture > Application Tier > Shareable Layer > Domain Entity

“Using inheritance judiciously is another aspect of
programming effectively with objects.”1

Behavioral Definition

A PED Domain Entity2 (DE) represents a physical entity with a unique identity.  That is, they are the nouns when designing an object model.

Structural Elements

  • Extends a base DE class (inheritance) such as:
    • AuditDE
    • UuidDE
      • ThelastUpdate fieldis used forbothauditingandversioning
        • Versioning supports both optimistic locking and cache refresh
    • UuidNoAuditDE
  • One DE relates to another DE typically via composition
  • Contains a single field for identity (no composite primary keys)
  • Implements two constructors and at least one immutable identity field:
    • A no-argument constructor
    • A second constructor with the identity parameter
    • A ‘getter’ implemented for the identity field with no ‘setter’
  • Typically contains field annotations and accessor methods only
  • Satisfies Template Methods as required

Here are some additional perspectives:

“Using a natural key rather than a generated key is a
bad, bad, bad, bad, bad practice.”3

Note: Agreeing whether a DE should contain encapsulated behavior (beyond accessor methods) is a significant architectural concern explicitly settled by an application development team formalizing their own Pattern Palette.

Class Diagram

Domain Entity

Source (from Getting Started)

References

  1. Kent Beck, Implementation Patterns, p. 22.
  2. This PED pattern is loosely informed by the ENTITY within Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software, p. 512 specifies an entity as “An object fundamentally defined not by its attributes, but by a thread of continuity and identity.”
  3. Scott Ambler, in person, at Ford Motor Company in August, 2011. Scott goes on to say that a natural key is a practical choice for a look-up object.