Learning Domain-Driven Design — Chapter 2, Part 1

The second session examines business-logic implementation. A Transaction Script organizes it around procedures and commits or rolls back the whole operation atomically. Distributed writes, retries, and idempotency hide behind the simplicity: the pattern suits supporting logic but is risky in a core domain.

Active Record is a similar procedural approach over objects and CRUD. Neither it nor an anemic domain model is treated as an unconditional antipattern; both are pragmatic for a simple model. A complex domain needs a domain model that separates business complexity from infrastructure and protects state transitions.

The model uses value objects, entities, aggregates, and domain services. A value object is identified by values and is normally immutable; an entity retains identity. An aggregate sets a transaction boundary and invariants, while eventual consistency applies between aggregates. A domain service calculates a rule without changing several aggregates together.

An event-sourced model stores domain events instead of one current snapshot. It enables auditing, debugging, new projections, and version-conflict handling, but requires event evolution and snapshots. To remove personal data, sensitive values can be encrypted with a disposable key or stored outside events.