도메인 레이어 질문

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!
먼저 유사한 질문이 있었는지 검색해 보세요.
서로 예의를 지키며 존중하는 문화를 만들어가요.

안녕하세요. 우빈님 두 가지 질문이 있습니다.

도메인 레이어에 Repository를 넣으셨는데 도메인과 Repository를 같이 두신 이유가 있으신가요?
현재 도메인 모델과 Jpa Entity를 동일하게 가져가고 있는데 이로인해서 겪으신 문제는 없으신가요? 엄격한 DDD를 위해서라면 도메인 모델을 JPA 엔티티로 쓰는 것이 아니라 JPA 엔티티에 Convert 메서드를 만들어서 처리하고 있더라구요. 이에 대한 우빈님의 생각이 듣고 싶습니다.

안녕하세요, wisehero 님!

1. 도메인 레이어에 Repository를 넣으셨는데 도메인과 Repository를 같이 두신 이유가 있으신가요?

2번 질문에서 말씀하신대로 DDD에서 이야기하는 구조입니다.
Repository는 도메인 모델의 CRUD를 담당하기 때문에, 그 추상적 개념은 도메인 레이어에 있어야 한다고 생각해요.
Repository가 인터페이스라, 실제로 CRUD가 동작하도록 구현하는 구현체는 외부 레이어에서 주입되고 있기도 하고요 ㅎㅎ

2. 현재 도메인 모델과 Jpa Entity를 동일하게 가져가고 있는데 이로인해서 겪으신 문제는 없으신가요? 엄격한 DDD를 위해서라면 도메인 모델을 JPA 엔티티로 쓰는 것이 아니라 JPA 엔티티에 Convert 메서드를 만들어서 처리하고 있더라구요. 이에 대한 우빈님의 생각이 듣고 싶습니다.

맞습니다. 엄격한 DDD라면 철저하게 분리하는 것이 맞는데요.
실무에서는 JPA를 사용하기로 한 프로젝트에서 JPA를 다른 기술로 변경하고자 하는 사례가 아직까지는 거의 없기 때문에, 편의상 JPA Entity 모델을 도메인 모델로 사용하는 경우가 많습니다.
Entity와 순수 도메인 모델을 매번 변환해주는 컨버팅 로직을 작성하는 것이 품이 많이 들기 때문이죠.

물론 반대로 팀에 따라서 우리는 이를 엄격하게 지켜보자, 하는 팀도 있어요.
팀원 모두가 동의한다면, 시도해볼 수 있는 좋은 형태라 생각해요.

나름의 트레이드오프라 생각해주시면 될 것 같네요 ㅎㅎ

도움이 되셨기를 바랍니다.
감사합니다 🙂

인프런 커뮤니티 질문&답변