Anemic Model (빈혈 모델)란?

**Anemic Domain Model(빈혈 도메인 모델)**은 객체지향 프로그래밍(OOP)의 핵심 개념을 충분히 활용하지 못한 도메인 모델을 의미합니다. 이는 도메인 객체가 데이터(필드)만 포함하고, 비즈니스 로직은 별도의 서비스 계층에서 처리하는 구조를 가질 때 발생합니다.

---

1. 특징

Anemic Model은 다음과 같은 특징을 가집니다.

1. 도메인 객체(엔티티, 밸류 객체)에는 데이터만 존재하고, 의미 있는 비즈니스 로직이 없음
2. 비즈니스 로직이 서비스 계층(Application Service)에 집중됨
3. Getter/Setter 메서드만 제공하는 단순한 데이터 구조 (DTO와 유사)
4. 객체지향보다는 절차지향적인 방식으로 개발됨

예제 코드 (Anemic Model)

public class Order {
    private Long id;
    private String status;

    public String getStatus() {
        return status;
    }

    public void setStatus(String status) {
        this.status = status;
    }
}

public class OrderService {
    public void completeOrder(Order order) {
        order.setStatus("COMPLETED");
    }
}

• Order 객체는 데이터만 가지고 있고, 비즈니스 로직이 없음
• OrderService에서 모든 로직을 처리함

---

2. 왜 문제인가?

1. 객체의 캡슐화(Encapsulation)가 깨짐
   • 객체의 상태를 직접 변경할 수 있어 일관성을 유지하기 어려움
   • setStatus("COMPLETED") 같은 메서드는 어디서든 호출될 수 있어 무결성을 보장하기 어려움
2. 도메인 모델의 책임이 사라짐
   • 도메인 객체가 단순한 데이터 저장소로 전락함
   • 도메인의 핵심 비즈니스 로직이 서비스 계층에 집중됨
3. 유지보수성과 확장성이 저하됨
   • 로직이 여러 서비스에서 중복될 가능성이 높음
   • 비즈니스 로직이 도메인 객체가 아닌 서비스 계층에 몰려 있어 변경 사항이 많아지면 코드가 복잡해짐
4. 객체지향보다는 절차지향적 코드가 됨
   • 객체가 자신의 행동을 스스로 수행하는 것이 아니라, 외부 서비스가 객체를 조작하는 방식이 됨

---

3. 풍부한 도메인 모델(Rich Domain Model)과 비교

Rich Domain Model (풍부한 도메인 모델) 예제

public class Order {
    private Long id;
    private String status;

    public Order() {
        this.status = "NEW";
    }

    public void complete() {
        if (!"NEW".equals(this.status)) {
            throw new IllegalStateException("Only new orders can be completed");
        }
        this.status = "COMPLETED";
    }

    public String getStatus() {
        return status;
    }
}

• Order 객체가 스스로 complete() 메서드를 제공하여 상태를 변경하도록 설계됨
• 도메인 객체가 비즈니스 로직을 포함하고 있어 응집도가 높아짐

비교 정리

	Anemic Model	Rich Domain Model
비즈니스 로직 위치	서비스 계층	도메인 객체
객체의 역할	데이터 보관소 (DTO 유사)	데이터 + 비즈니스 로직 포함
객체지향 원칙 준수 여부	OOP 원칙 위반	OOP 원칙 준수
응집도(Cohesion)	낮음 (로직이 분산됨)	높음 (객체가 자신의 책임을 가짐)
유지보수성	낮음 (서비스 계층이 비대해짐)	높음 (도메인 객체가 책임을 가짐)

---

4. Anemic Model이 반드시 나쁜가?

언제 사용하면 괜찮을까?

• 단순한 CRUD 애플리케이션
• 데이터 중심적인 서비스 (예: 리포팅, 데이터 분석)
• 도메인 로직이 거의 없는 경우

언제 피해야 할까?

• 비즈니스 규칙이 복잡한 도메인 (예: 금융, 전자상거래, 의료 시스템 등)
• 도메인 모델이 변화가 많고 확장 가능성이 있는 경우

---

5. 결론

• Anemic Model은 객체지향적인 설계 원칙을 따르지 않으며, 유지보수성과 확장성이 낮음
• 도메인 객체가 자신의 상태와 행동을 스스로 관리하는 Rich Domain Model을 지향하는 것이 좋음
• 하지만 데이터 중심 시스템에서는 Anemic Model도 적절할 수 있음

👉 DDD(Domain-Driven Design)를 적용하려면 Anemic Model을 피하고, 도메인 객체가 비즈니스 로직을 포함하는 구조로 개선하는 것이 중요합니다.