Repositories & When to Use DDD

Two things left to make DDD-lite usable: the tactical supporting cast - repositories, domain services, and factories, the objects that surround your aggregates - and the honest question every senior asks before adopting a methodology: is this worth it here? DDD is an investment, and like every pattern in this path, it pays off against real complexity and is dead weight against simple CRUD.

Repositories: collection-like access to aggregates

A repository provides the illusion of an in-memory collection of aggregates, hiding how they're actually stored. Crucially, there's one repository per aggregate root - you don't get a repository for an internal entity like Posting; you load the whole Account aggregate through AccountRepository:

interface AccountRepository {                 // an abstraction owned by the domain (Dependency Inversion!)
    Optional<Account> findById(AccountId id);
    void save(Account account);               // persists the whole aggregate
    List<Account> findOverdrawn();            // domain-meaningful queries
}

The interface lives in the domain and speaks the ubiquitous language (findOverdrawn, not selectWhereBalanceLt0); the implementation lives in the infrastructure layer (JPA, JDBC). This is Dependency Inversion at the architectural scale - and exactly the seam hexagonal architecture formalizes next module. Spring Data's Repository interfaces are this pattern productized.

Domain services and factories

Not every behavior belongs on an entity or value object. Two supporting types catch the rest:

• Domain service - a stateless operation that doesn't naturally belong to a single aggregate, usually because it coordinates several. "Transfer money from account A to account B" touches two Account aggregates, so it lives in a TransferService, expressed in domain terms - not shoehorned into one Account. (Don't confuse a domain service with an application/Spring @Service; a domain service holds real business logic, not just orchestration.)
• Factory - encapsulates complex aggregate creation when a constructor isn't enough (enforcing invariants across a cluster of objects at birth). You met factories as a pattern; in DDD they specifically guard the creation of well-formed aggregates.

A tell that logic is homeless: if it doesn't fit on an aggregate (it spans several) and isn't creation, it's probably a domain service. Resist dumping it into a bloated "manager" - that's how you get back to LedgerManager.

When DDD is worth it - and when it isn't

Here is the senior verdict. DDD's ceremony - aggregates, value objects, contexts, ubiquitous language - is an investment that pays back when the domain is complex:

Use DDD when:

• The business logic is rich and central - intricate rules, many edge cases, real domain complexity (banking, insurance, logistics, healthcare).
• The domain is your competitive advantage and will be worked on for years.
• You have access to domain experts to build a ubiquitous language with.

Skip (most of) DDD when:

• It's essentially CRUD - forms over data with thin logic. A ProductController → ProductService → ProductRepository over a few fields needs no aggregates or contexts; the ceremony is pure overhead.
• The app is small, short-lived, or a prototype.
• The complexity is technical, not domain (a high-throughput pipeline's hard part is performance, not business rules).

Even then, DDD-lite pays off broadly: value objects instead of primitives, a ubiquitous language, and respecting aggregate boundaries improve almost any codebase cheaply. You don't have to adopt the whole methodology to steal its best ideas - which is exactly the spirit of this module.