Domain Entity (DE)

Architecture > Application Tier > Shareable Layer > Domain Entity

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

Domain Entities2 (DE) are typically a Java Bean representation of a physical entity with a unique identity.  One DE relates to a second DE typically via composition.

A PED DE:

  • Extends a base DE class (inheritance) such as:
    • AuditDE
    • UuidDE
      • The lastUpdate field is used for both auditing and versioning
        • Versioning supports both optimistic locking and cache refresh
    • UuidNoAuditDE
  • 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.

Design (example demonstrating Abstraction Architecture)

Domain Entity

Source (testing example from Getting Started)

References

  1. Kent Beck, Implementation Patterns, p. 22.
  2. The PED DE 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.