나의 주관적인 정리이다.

Anemic Domain Model

빈약한 도메인 객체 (Anemic Domain Object)

데이터 중심
비지니스가 외부 구성에 의존

특징

• 데이터를 중심으로한 도메인
• 주로 데이터만 포함하고, 비지니스는 별도의 서비스 계층에 위임
• 메서드는 주로 getter, setter만 포함
  

장점

• 구현이 빠름

  • 단순한 구조로 빠르게 구현이 가능
  • 간단한 프로젝트나 초기 단계에서 빠른 개발이 가능

• 테스트가 편함

  • 테스트 데이터를 쉽게 만들 수 있음
  • 도메인이 별도의 비지니스를 포함하고 있지않아 복잡한 테스트가 필요없음

• 관심사 분리

  • 데이터와 비지니스를 각각 독립적으로 변경 가능

단점

• OOP 위반

  • OOP의 이점을 활용하지 못함
  • 도메인의 표현력이 떨어짐
  • 객체의 내부 상태가 외부로 모두 노출되므로 캡슐화 위반

• 비지니스 로직 분산

  • 중복코드 발생
    • 특정 비지니스 로직이 여러 서비스에서 쓰인다면 중복된 로직이 생긴다.
  • 일관성 있는 규칙 적용, 유지가 힘들다.
    • 여러 서비스에 퍼져있는 동일한 비지니스 로직 중 하나를 수정하려면 해당 규칙이 있는 모든 곳을 찾아서 수정해야함

• 유지보수성 저하

  • 비지니스 로직의 변경이나 확장이 어렵다.
    • 하나의 비지니스 로직을 3곳의 서비스에서 사용한다 했을 때 이를 다 확인해야 한다.
    • 다른곳을 빼먹었더라고 검증되기 전까지 이는 에러를 뱉지 않는다.(에러가 안나오고 비지니스만 잘못될 수도 있다.)

• 테스트 복잡도 증가

  • 모델에 대한 자체적인 유효성 테스트가 불가능하다.
  • 비지니스를 포함하고 있는 계층의 테스트가 복잡해진다.

Rich Domain Model

풍부한 도메인 객체 (Rich Domain Object)

객체 지향적
비지니스가 포함되어 주체적

특징

• OOP 원칙을 따르는 도메인
• 도메인이 데이터와 행위를 포함
• 비지니스 로직이 도메인 안에 존재
• 도메인이 행위를 직접 표현함으로써 표현력이 높음
  

RDM을 사용하면 DDD를 하는건가요?

DDD는 비즈니스 도메인을 중심으로 소프트웨어를 모델링, 설계하는 방법론이다.
DDD의 핵심개념중 하나가 RDM인것은 맞지만 RDM이 DDD인것은 아니며 DDD가 RDM인것 또한 아니다.

장점

• OOP 원칙 준수

  • 캡슐화 가능
  • 다형성사용시 확장성 증가

• 비지니스 응집도 증가

  • 데이터와 행위가 객체 안에 존재
  • 비지니스 로직 중앙화로 일관성을 유지하기 좋음
  • 재사용성 증가로 인한 중복 코드 감소

• 유지보수성 증가

  • 도메인의 표현력이 높아짐
  • 비지니스 도메인의 이해 난이도가 낮아짐
  • 중앙화된 로직으로 유지보수성 증가

• 단위 테스트 용이성

  • 비지니스 로직이 도메인에 존재하기 때문에 복잡한 의존성 없이 비지니스 테스트 가능
  • 모델에 대한 유효성 테스트 가능

단점

• 복잡성 증가

  • 비지니스에 따라 도메인의 복잡도가 높아질 수 있음
  • 복잡도가 높은 도메인의 이해 및 유지보수가 어려워질 수 있음

• 성능 이슈

  • 도메인에 비지니스 로직이 포함되면서 DB 조회시 불필요한 비용 발생 가능

• 테스트 복잡성

  • 단위 테스트에서의 장점은 강해지나 통합테스트의 복잡성이 증가할 수 있음
  • 도메인의 복잡도에 따라 단위 테스트의 복잡도 또한 증가

• 러닝 커브가 가파름

  • 복잡한 도메인에 대해 많은 시간과 노력 그리고 지속적인 관심이 필요

• 설계비용 증가

  • 초기 설계에서 도메인을 정확히 이해하고 설계하는데 시간이 많이 듬

요약

• ADM은 상대적으로 간단하나 빈약하다.
• RDM은 복잡하나 견고하다.
• 장점만 존재하는건 없다.
• 상황에 맞게 적절한 선택을 하자(RDM, ADM)
• RDM을 사용한다면 많은 노력과 관심을 갖자