2nd/10_Wiki/Topic_Programming/AI_and_ML/Anaemic Domain Model.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

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

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

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)

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)

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

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