---
id: wiki-2026-0508-anaemic-domain-model
title: Anaemic Domain Model
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [빈약한 도메인 모델, transaction script, getter-setter model, data class]
duplicate_of: none
source_trust_level: B
confidence_score: 0.88
verification_status: applied
tags: [ddd, anti-pattern, anaemic, transaction-script, oop, domain-model, architecture]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: Java / C# / TypeScript
  framework: DDD / Clean Architecture
---

# Anaemic Domain Model

## 📌 한 줄 통찰
> **"매 data 만 의 class + 매 logic 의 service 의 split"**. Martin Fowler 가 anti-pattern 가 — 매 OOP 의 procedural 화. 매 simple CRUD OK 가, 매 complex domain 의 maintainability 망가짐. **DDD 의 Rich Domain Model 가 답**.

## 📖 핵심

### 매 정의
- 매 entity class 가 getter / setter 만.
- 매 business logic 가 service / manager class.
- 매 data ≠ behavior 의 OO 위반.

### Fowler 의 비판 (2003)
> "It looks like the real thing... but when you look at the behavior, you realize there is hardly any behavior on these objects, making them little more than bags of getters and setters."

→ 매 procedural 의 disguise.

### 매 anti-pattern 의 이유
1. **OOP 의 위반**: 매 encapsulation X, data ≠ behavior.
2. **매 invariant 의 violate**: 매 entity 의 invariant 의 service 가 알아야.
3. **Logic 의 분산**: 매 같은 entity 의 logic 의 매 service 의 spread.
4. **Test 어려움**: 매 service 의 entity mock 의 burden.
5. **DDD 의 Bounded Context 의 약화**.

### Anaemic vs Rich

#### Anaemic
```ts
class Order {
  id: string;
  items: Item[];
  total: number;
  status: 'pending' | 'paid' | 'shipped';
  // 매 getter / setter 만.
}

class OrderService {
  pay(order: Order, amount: number) {
    if (order.status !== 'pending') throw new Error();
    if (amount < order.total) throw new Error();
    order.status = 'paid';
    // 매 logic 의 service.
  }
}
```

→ 매 invariant 의 service 가 알아야. 매 다른 service 의 같은 logic 반복.

#### Rich
```ts
class Order {
  private status: 'pending' | 'paid' | 'shipped' = 'pending';
  
  pay(amount: Money) {
    if (this.status !== 'pending') throw new InvalidOrderState();
    if (amount.isLessThan(this.total)) throw new InsufficientPayment();
    this.status = 'paid';
    this.events.push(new OrderPaid(this.id));
  }
  
  ship() {
    if (this.status !== 'paid') throw new InvalidOrderState();
    this.status = 'shipped';
  }
}
```

→ 매 invariant 의 entity 자체. 매 logic 의 cohesive.

### 매 OK 가 case
- **CRUD-only**: 매 simple form / report. 매 logic 거의 없음.
- **Microservice 의 small**: 매 single domain 의 작은 service.
- **Reporting / analytics**: 매 read-only.
- **DTO**: 매 transport 의 data 만.

### 매 ❌ case
- **Complex domain**: 매 ordering, billing, accounting.
- **매 invariant 의 많음**: 매 entity 의 rule.
- **Long-lived codebase**: 매 maintenance.
- **Team 의 큰**: 매 logic 의 spread → bug.

### DDD 의 답
- **Aggregate**: 매 entity 의 root 가 invariant 보호.
- **Value Object**: 매 immutable + behavior.
- **Domain Service**: 매 entity 의 across 의 logic 만.
- **Repository**: 매 persistence.
- **Domain Event**: 매 state change 의 명시.

## 💻 패턴

### Aggregate root (DDD)
```ts
class CartAggregate {
  private items: Map<ProductId, CartItem> = new Map();
  
  add(productId: ProductId, qty: number) {
    if (qty <= 0) throw new InvalidQuantity();
    const existing = this.items.get(productId);
    if (existing) existing.increment(qty);
    else this.items.set(productId, new CartItem(productId, qty));
  }
  
  remove(productId: ProductId) {
    if (!this.items.has(productId)) throw new ItemNotFound();
    this.items.delete(productId);
  }
  
  total(prices: Map<ProductId, Money>): Money {
    return [...this.items.values()].reduce(
      (sum, item) => sum.add(prices.get(item.productId)!.times(item.qty)),
      Money.zero('USD'),
    );
  }
}
```

### Value Object (immutable + behavior)
```ts
class Money {
  constructor(
    public readonly amount: bigint,
    public readonly currency: string,
  ) {}
  
  add(other: Money): Money {
    if (this.currency !== other.currency) throw new CurrencyMismatch();
    return new Money(this.amount + other.amount, this.currency);
  }
  
  times(n: number): Money { return new Money(this.amount * BigInt(n), this.currency); }
  
  isLessThan(other: Money): boolean {
    if (this.currency !== other.currency) throw new CurrencyMismatch();
    return this.amount < other.amount;
  }
  
  static zero(currency: string) { return new Money(0n, currency); }
}
```

### Domain event
```ts
class Order {
  private events: DomainEvent[] = [];
  
  pay(amount: Money) {
    // ...
    this.events.push(new OrderPaid(this.id, amount, new Date()));
  }
  
  pullEvents(): DomainEvent[] {
    const out = this.events;
    this.events = [];
    return out;
  }
}

// Repository 가 save 시 publish.
```

## 🤔 결정 기준
| 상황 | 모델 |
|---|---|
| Simple CRUD | Anaemic OK |
| Complex business rule | Rich (DDD) |
| Microservice (small) | Anaemic OK |
| Microservice (core domain) | Rich |
| DTO / API contract | Anaemic (data only) |
| Long-lived codebase | Rich |

**기본값**: 매 core domain = Rich. 매 supporting = Anaemic 가 OK.

## 🔗 Graph
- 부모: [[Domain-Driven-Design]]
- 변형: [[Transaction-Script]]
- 응용: [[Aggregate-Root]] · [[Value-Object]] · [[Domain-Event]]
- Adjacent: [[Bounded-Context]] · [[CQRS]] · [[Event-Sourcing]] · [[Hexagonal-Architecture]]

## 🤖 LLM 활용
**언제**: 매 backend service design 의 review. 매 DDD 의 적용 결정. 매 legacy 의 refactor.
**언제 X**: 매 quick prototype. 매 simple admin tool.

## ❌ 안티패턴
- **모든 domain 의 anaemic**: 매 OOP 가치 X.
- **Service 의 logic 폭발**: 매 god object.
- **Invariant 의 service / controller 분산**: 매 inconsistent.
- **모든 domain 의 rich**: 매 over-engineering. 매 simple CRUD 의 burden.
- **Anaemic 의 ORM 강제**: 매 framework 의 lock-in.

## 🧪 검증 / 중복
- Verified (Fowler 의 article + DDD 책).
- 신뢰도 B.
- Related: [[Transaction-Script]] · [[Domain-Driven-Design]] · [[Aggregate-Root]].

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — Fowler 비판 + Rich 예제 + Aggregate code |