블로그에 게시하는 위 글은 전체적인 내용 정리가 아닌
책을 읽으면서 새로 알게된 내용이나 제가 중요하다고 생각하는 내용을 정리한 글입니다.
1) 표현영역
2) 응용 영역
3) 도메인 영역
4) 인프라 스트럭처 영역
책 내용을 기반으로 따로 정리해서 포스팅
1) 엔티티
고유의 식별자와 자신만의 라이프 사이클을 가짐
→ 고유한 개념을 표현하는데 사용
2) 밸류
식별자를 가지고 있지 않음
→ 개념적으로 하나인 도메인 객체의 속성을 표현
엔티티 속성, 다른 밸류 타입의 속성으로도 사용 가능
3) 애그리거트
4) 리포지터리
5) 도메인 서비스
Q. DB의 Entity == 도메인 모델의 Entity ??
A. 아니다!
도메인 모델의 엔티티 = 데이터 + 도메인 기능을 함께 제공한다.
상위 수준에서 모델을 볼 수 있으며, 관련 객체를 하나로 묶은것
→ 관련 객체들을 객체 군집 단위로 묶어 모델을 바라보면 큰 틀에서 도메인 모델 관리 O
애그리거트에 속해있는 엔티티, 밸류를 이용해서 구현해야하는 기능을 제공하는 것은 루트 엔티티이다.
도메인 객체를 물리적인 저장소에 보관해야하는데, 이를 보관하기 위해 구현하는 도메인 모델
리포지터리를 통해 찾거나 저장하는 단위는 엔티티 루트이다.
레포지토리 자체 → 고수준 모듈
레포지토리를 구현한 클래스 → 저수준 모듈
리포지터리의 사용 주체 → 응용 서비스
표현영역에서
응용서비스
인프라 스트럭처는 표현, 응용, 도메인 영역을 지원한다.
DIP를 적용하면 좋지만, 무조건적인 것은 X
가장 좋은 방법은 DIP가 주는 장점을 해치지 않는 범위에서 응용, 도메인 영역에서 구현 기술에 대한 의존을 가지는 것
모듈 구성은 취향(이라고 생각한다.)
하지만 한 패키지에 너무 많은 타입이 몰려서 코드를 찾기 어렵게할 수 있다.