Keeping the Domain Pure

The Dependency Rule has a demanding consequence people love to skip: if the domain depends on nothing outward, then the domain must contain no framework code - no JPA @Entity, no Spring @Component, no Jackson annotations. That purity is the whole payoff, but it isn't free: it forces mapping at the boundary between your clean domain models and the framework's models. This lesson is about doing that mapping well and deciding, honestly, when the purity is worth its price.

The temptation and the cost of skipping it

The seductive shortcut is to use your JPA entity as your domain model - one class, annotated, doing double duty:

@Entity                                    // 🚩 a framework annotation in your "domain"
@Table(name = "accounts")
class Account {
    @Id @GeneratedValue Long id;
    @Column BigDecimal balance;
    // ...business methods mixed with persistence concerns...
}

It works, and for simple apps it's a legitimate pragmatic choice. But it quietly couples your domain to JPA: the @Entity needs a no-arg constructor (so you can't enforce invariants at construction), lazy-loading proxies leak into business logic, and your "pure" rules now can't run without a persistence provider on the classpath. The database's shape starts dictating the domain's shape.

Mapping at the boundary

The pure approach keeps two separate models and maps between them in the adapter:

// DOMAIN - pure, no annotations, enforces its own invariants
class Account {
    private final AccountId id;
    private Money balance;
    public void withdraw(Money amount) { /* invariant enforced */ }
}

// PERSISTENCE - a separate JPA entity, lives in the infrastructure adapter
@Entity @Table(name = "accounts")
class AccountEntity { @Id String id; BigDecimal balance; String currency; }

// The ADAPTER maps between them - this is where the two worlds meet
class JpaAccountRepository implements AccountRepository {
    public Optional<Account> findById(AccountId id) {
        return jpa.findById(id.value()).map(this::toDomain);     // entity → domain
    }
    public void save(Account a) { jpa.save(toEntity(a)); }        // domain → entity
    private Account toDomain(AccountEntity e) { ... }
    private AccountEntity toEntity(Account a) { ... }
}

The domain never sees AccountEntity; the rest of the app never sees JPA. The same discipline applies at the web edge (map between domain objects and request/response DTOs, so Jackson annotations don't leak inward) and at message boundaries.

The honest trade-off

Mapping code is real code - boilerplate you write, test, and maintain, and an extra model to keep in sync. Be honest about the ledger:

The purity buys you:

• A domain testable with zero infrastructure (next lesson) - no database, no Spring context.
• Freedom to change persistence, serialization, or framework without touching business rules.
• A domain model shaped by the business, not by table columns or JSON fields.
• Invariants enforceable at construction (no forced no-arg constructor).

It costs you:

• Mapping boilerplate (mitigated by MapStruct or a few helper methods).
• A second set of model classes to maintain.
• More ceremony - overkill for a simple CRUD screen.

The senior call: pay for purity where the domain logic is rich and long-lived, and take the pragmatic single-model shortcut where it's thin CRUD - exactly the DDD "is it worth it?" judgment applied to persistence. Consistency within a codebase matters too; don't map religiously in one module and not another.