빈혈 모델은 DDD인가요?

"빈혈 모델(Anemic Domain Model)"은 DDD(Domain-Driven Design)의 개념과 대조되는 설계 방식입니다. 즉, 빈혈 모델은 DDD의 원칙을 따르지 않는 모델로 볼 수 있습니다.

빈혈 모델(Anemic Domain Model)이란?

빈혈 모델은 객체가 비즈니스 로직 없이 데이터만을 보유하고, 모든 로직이 서비스 계층에 집중되는 구조를 의미합니다. 주로 다음과 같은 특징이 있습니다:

• 엔티티(Entity): Getter/Setter만 존재하고, 비즈니스 로직이 없음.
• 서비스(Service): 모든 도메인 로직이 서비스 계층에서 수행됨.
• DTO(Data Transfer Object)와 유사: 객체는 데이터를 전달하는 역할만 함.

이런 구조는 객체지향적이라기보다는 절차지향적인 설계에 가까우며, DDD에서 권장하는 "도메인 모델 패턴(Rich Domain Model)"과는 반대되는 개념입니다.

---

DDD에서는 빈혈 모델을 어떻게 볼까?

DDD에서는 빈혈 모델을 안티 패턴(Anti-pattern) 으로 간주하는 경우가 많습니다. DDD의 핵심은 "도메인 모델이 자신의 상태와 비즈니스 로직을 함께 가지도록 하는 것"입니다. 이를 풍부한 도메인 모델(Rich Domain Model) 이라고 합니다.

빈혈 모델의 문제점

• 캡슐화(Encapsulation) 부족: 데이터와 비즈니스 로직이 분리되어 유지보수가 어려움.
• 응집도(Cohesion) 저하: 도메인 로직이 서비스 계층에 집중되어 재사용성이 떨어짐.
• 객체지향적이지 않음: 객체가 단순한 데이터 구조로 전락함.

DDD에서 권장하는 구조: 풍부한 도메인 모델(Rich Domain Model)

• 엔티티(Entity)와 밸류(Value Object) 가 비즈니스 로직을 포함.
• 도메인 서비스(Domain Service): 특정 엔티티에 포함하기 어려운 로직을 별도로 관리.
• 응집도 높은 모델을 유지하여 유지보수성과 확장성을 높임.

---

언제 빈혈 모델을 사용할 수 있을까?

빈혈 모델이 항상 나쁜 것은 아닙니다. 다음과 같은 경우에는 빈혈 모델이 적절할 수 있습니다:

1. 단순한 CRUD 시스템: 도메인 로직이 거의 없는 단순한 애플리케이션.
2. 트랜잭션 스크립트(Transaction Script) 패턴이 더 적합한 경우: 복잡한 도메인 로직이 필요하지 않은 환경.

하지만 DDD를 적용하려면 가능한 한 도메인 모델이 도메인 로직을 가지도록 설계하는 것이 중요합니다.

---

결론

• 빈혈 모델은 DDD의 도메인 모델 패턴과 반대되는 개념이며, 일반적으로 DDD의 원칙을 따르지 않음.
• DDD에서는 도메인 모델이 로직을 포함하는 풍부한 도메인 모델(Rich Domain Model) 을 권장함.
• 하지만 빈혈 모델이 무조건 나쁜 것은 아니며, 단순한 CRUD 애플리케이션에서는 유용할 수 있음.

따라서 빈혈 모델을 사용하고 있다면, 해당 시스템이 DDD를 적용해야 하는지 고민해보고 적절한 패턴을 선택하는 것이 중요합니다. 🚀