domain-driven-design

Design aggregates from invariants, not entity relationships. Include only the data needed to enforce consistency rules during state changes, reference other aggregates by ID, and modify one aggregate per transaction. Accept child IDs rather than child objects in root methods.

A domain service contains business logic operating on domain types, like pledgeContribution. A use case is application orchestration only: it loads aggregates via repositories, calls domain services, and saves results. You can tell them apart by their signatures.

Use explicit return values when side effects stay within one aggregate or transaction. Add domain events when side effects cross aggregate boundaries, other bounded contexts must react, or you need an audit trail. Start without events and add them when coordination demands it.

Use discriminated union result types for expected business outcomes like rule violations, since the compiler enforces exhaustive handling. Reserve exceptions for programmer mistakes, invariant violations, and infrastructure failures that no business rule can handle.

Avoid DDD for simple CRUD applications with no business rules, technical or infrastructure-focused projects, and projects without access to a domain expert. Start with a glossary and value objects, adding aggregates and bounded contexts only when domain complexity demands them.