domain-logic-implementation

To enforce domain invariants, place lifecycle rules and state transition checks directly near the owning aggregate or domain service to reject invalid changes before persistence. This establishes a single-source rule authority, preventing duplicated inconsistent checks across controllers and services while keeping aggregates consistent.

Duplicated domain logic across UI, controllers, and persistence causes bugs because inconsistent rule enforcement allows invalid states to be saved, surfacing only during edge cases. Centralizing invariants within a domain authority ensures each rule has one owner, eliminating contradictory behavior across application layers.

The best way to design a domain implementation contract is to define explicit success and failure outcomes for the new aggregate behavior, ensuring the logic remains free from transport and persistence concerns. Enforce boundary-focused tests to validate that the domain service correctly rejects invalid transitions.

Keep domain operations independent by placing calculations, policies, and invariants near the owning domain model or value object, strictly avoiding framework or ORM object references inside the domain logic. This transport-agnostic approach ensures the domain service maintains rule authority without external dependencies.

Use a domain service for rule placement when an invariant or calculation spans multiple domain models or does not naturally belong to a single aggregate. Centralizing the policy within the domain service ensures state transition safety and prevents duplicated inconsistent checks across layers before persistence.

Test invalid lifecycle transitions by writing boundary-focused tests that specify explicit failure outcomes when the domain authority rejects an invalid state change. This validates that the aggregate or value object enforces invariants and prevents invalid data from reaching the persistence layer.