티스토리 뷰
발생일: 2009.09.22
문제:
현재 담당하고 있는 시스템은 스트럿츠로 구현되어 있다.
다른 일반 자바 엔터프라이즈 시스템처럼,
프리젠테이션 레이어 - 서비스 레이어 - 데이터액세스 레이어의 3-tier 구조다.
그리고 그 가운데 데이터 전달을 위한 도메인 객체가 있다.
처음 프로젝트를 할 때에는 이게 표준이구나 싶어서 별 생각없이 구현했는데,
어느 날 문득 궁금해졌다.
왜 도메인 객체들을 단순 VO로만 사용하는 걸까...?
좀 더 객체지향적으로 도메인 객체를 활용하면 좋지 않을까...?
해결책:
위와 같이 단순한 데이터 값의 저장을 위한 VO 역할만 하는 도메인 객체를 anemic domain 이라고 한다.
anemic domain model의 한계를 느끼고 나타난 것이
도메인 객체에 직접 도메인과 관련된 비지니스 로직을 포함하는 도메인 모델이다.
이를 rich domain model 또는 smart domain model 이라 한다. (이게 원래의 java object의 형태 아닐까?)
그리고 이런 rich domain model을 가지고 시스템을 설계하는 것을 DDD(Domain Driven Design)이라고 한다.
스프링프레임웍의 POJO 와 DI 개념이 나오면서 이슈가 되기 시작했다고 한다.
DDD의 장점을 잘 정리해놓은 마소 기사가 있다. 스프링프레임웍과 DDD(pdf)를 참고해보자.
그리고 DDD 사용에 대해 주의점을 알려주는 먹기엔 덜익은 DDD와 Rich Domain Model 포스트도 읽어보자.
문제:
현재 담당하고 있는 시스템은 스트럿츠로 구현되어 있다.
다른 일반 자바 엔터프라이즈 시스템처럼,
프리젠테이션 레이어 - 서비스 레이어 - 데이터액세스 레이어의 3-tier 구조다.
그리고 그 가운데 데이터 전달을 위한 도메인 객체가 있다.
처음 프로젝트를 할 때에는 이게 표준이구나 싶어서 별 생각없이 구현했는데,
어느 날 문득 궁금해졌다.
왜 도메인 객체들을 단순 VO로만 사용하는 걸까...?
좀 더 객체지향적으로 도메인 객체를 활용하면 좋지 않을까...?
해결책:
위와 같이 단순한 데이터 값의 저장을 위한 VO 역할만 하는 도메인 객체를 anemic domain 이라고 한다.
anemic domain model의 한계를 느끼고 나타난 것이
도메인 객체에 직접 도메인과 관련된 비지니스 로직을 포함하는 도메인 모델이다.
이를 rich domain model 또는 smart domain model 이라 한다. (이게 원래의 java object의 형태 아닐까?)
그리고 이런 rich domain model을 가지고 시스템을 설계하는 것을 DDD(Domain Driven Design)이라고 한다.
스프링프레임웍의 POJO 와 DI 개념이 나오면서 이슈가 되기 시작했다고 한다.
DDD의 장점을 잘 정리해놓은 마소 기사가 있다. 스프링프레임웍과 DDD(pdf)를 참고해보자.
그리고 DDD 사용에 대해 주의점을 알려주는 먹기엔 덜익은 DDD와 Rich Domain Model 포스트도 읽어보자.
반응형
댓글
공지사항