강의

멘토링

로드맵

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

개foot님의 프로필 이미지
개foot

작성한 질문수

Microservice 구현 (with EDA,Hexagonal, DDD)

외부영역 구현(프레임워크 헥사곤)-OR매핑 및 저장소 어댑터구현

강의보다 바로 여쭤봅니다.

작성

·

19

0

안녕하세요. 강의를 보다가 패키지 구조 패턴이 궁금해졌습니다.

 

강의에서는 JPA 매핑을 위해 entity 객체를 framework → jpaadapter → entity 패키지 아래에 두어야 한다고 말씀하셨는데, 실제로는 model에 작업하신 것처럼 보였습니다.


실무에서는 보통 jpaadapter 패키지에 entity 패키지를 따로 만들어서 강의에서 model에 하셨던 작업을 진행하시는 건가요?

또한 만약 framework → jpaadapter → entity 패키지 구조를 따른다면, domain → model 아래 객체들과의 관계나 역할 구분 그리고 소스 구성은 어떻게 되는지도 궁금합니다.

답변 2

0

han jeong heon님의 프로필 이미지
han jeong heon
지식공유자

안녕하세요 강의자 한정헌입니다. 답변드리면

1. 강의에서 model을 사용한 이유

  • 강의에서는 두가지를 분리하여 구조를 잡으면 아무래도 복잡해 지고, 핵심 개념 전달이 어렵기 때문에 model 에 JPA 매핑을 했습니다.

  • 실제로는 위에 AI가 답변한 것처럼 Hexagonal Architecture에서 domain modelpersistence entity는 서로 다른 책임을 가지므로 분리하는 게 맞습니다.

  • 다만 실무에서도 이는 비지니스 또는 마이크로서비스 성격에 따라, 엄격하게 헥사고널 아키텍처를 준수할 수 있고, 어느정도 모델 내부에 or mapping를 함께 하는 타협을 진행할 수도 있을 것 같습니다.

2. 헥사고널 아키텍척에서의 일반적인 구성

  • 엄격하게 준수하려고 한다면 보통 아래와 같이 패키지를 나누어 관리합니다.

     

framework
 └── jpaadapter
      └── entity   ← JPA Entity 클래스들 위치
domain
 └── model        ← 순수 비즈니스 모델 (애그리게이트 루트, VO 등)

3. 관계와 역할 구분

 

이렇게 구분 했을 때 책임 및 특징은 다음과 같아요.

  • domain.model :비즈니스 규칙과 도메인 로직 . JPA, Spring 등 외부 기술 의존 없음

  • jpaadapter.entity :DB 매핑 전용 클래스 , @Entity, @Table 등 JPA Annotation 사용

  • 두 계층은 Mapper를 통해 연결합니다.

    • Entity Domain Model 변환 코드가 이 계층에서 담당됩니다.

  • 이렇게 하면 도메인은 프레임워크에 독립적으로 유지되고, JPA 교체나 다른 persistence 전략 도입 시 영향이 최소화됩니다.

답변이 되었으면 좋겠습니다. 감사합니다. ^ ^

개foot님의 프로필 이미지
개foot
질문자

선생님, 추가로 mapper 관련해서 궁금한 점이 있습니다.

  1. 위치
    보통 mapper 패키지는 domain.model 쪽에 두는지, framework.jpaadapter 쪽에 두는지, 아니면 별도의 계층(interfacesapplication)으로 분리해서 관리하는지요? 실무에서는 어떤 기준으로 위치를 정하는지 궁금합니다.

  2. 구현 방식
    예를 들어 이런 방식들이 있는데요 (참고로 ai로 방법을 가져왔습니다):

  • 정적 유틸/Converter 클래스

    public class UserMapper {
        public static User toDomain(UserEntity e) {
            return new User(e.getId(), e.getName());
        }
        public static UserEntity toEntity(User d) {
            return new UserEntity(d.getId(), d.getName());
        }
    }
    
  • MapStruct 같은 코드 생성 기반 매퍼

    @Mapper(componentModel = "spring")
    public interface UserMapper {
        User toDomain(UserEntity entity);
        UserEntity toEntity(User domain);
    }
    
  • Repository 계층에서 매핑 처리

    @Repository
    public class UserRepository {
        private final JpaUserRepository repo;
        
        public User findById(Long id) {
            return UserMapper.toDomain(repo.findById(id).orElseThrow());
        }
        
        public void save(User user) {
            repo.save(UserMapper.toEntity(user));
        }
    }
    

이런 방식 중에서 실제 프로젝트에서는 어떤 방법을 더 많이 사용하셨는지, 그리고 규모나 복잡도에 따라 어떤 방식을 추천하시는지 궁금합니다.

  1. 선생님 경험
    개인적으로 최근 프로젝트에서는 어떤 위치/방식을 주로 쓰셨는지, 가능하다면 간단한 예제 코드도 함께 공유해 주시면 도움이 될 것 같습니다.

han jeong heon님의 프로필 이미지
han jeong heon
지식공유자

움 제가 항상하는 방법보다는 서비스 규모나 관점에 따라 매번 다를 것 같은데요. 구분해 보면,

1. domain.model 쪽에 두는 경우

  • 장점: 도메인이 주도적으로 외부와 변환 책임을 가진다고 보는 관점.

  • 적용 상황:

    • 작은 규모 프로젝트

    • 도메인 모델이 단순하고 변환 로직이 크지 않을 때

  • 예시: UserMapperUserEntity User 변환 담당, domain.model 하위에 둠.


2. framework.jpaadapter 쪽에 두는 경우

  • 장점: JPA Entity는 Infra 영역이므로, Infra와 Domain 사이 연결 책임도 Infra에서 맡긴다고 보는 관점.

  • 적용 상황:

    • DDD 원칙을 엄격히 적용하는 경우

    • 여러 Persistence Adapter(JPA, Mongo, Redis 등)가 공존할 수 있는 구조

  • 예시: UserJpaMapperframework.jpaadapter 하위에 존재, JPA Entity 변환만 담당.


3. application 계층에 두는 경우

  • 장점: Domain과 Infra 양쪽에 중립적 위치. 변환을 오케스트레이션 계층에서 담당.

  • 적용 상황:

    • 대규모 시스템

    • 다중 어댑터(DB, 외부 API 등)가 붙고, 매핑 책임이 복잡해질 때

  • 예시: UserDataMapperapplication 계층에 위치해 Domain Entity, Domain DTO 등을 모두 다룸.

이런 케이스 들이 있겠네요.

음 그리고 저같은 경우에는 프로젝트 상황에 따라, 비지니스 및 팀원들 성향에 따라 매번 다르다고 보시면 될 것 같습니다.

0

안녕하세요, 인프런 AI 인턴입니다. 개foot님.

패키지 구조에 관한 질문을 주셨네요. 강의에서 언급된 framework → jpaadapter → entity 패키지 구조는 헥사고날 아키텍처와 맞물려 외부 인터페이스와 내부 도메인 로직을 분리하기 위한 설계 전략입니다. 이를 통해 외부의 변화가 내부 도메인 로직에 영향을 주지 않도록 하는 것이 목적입니다.

  1. JPA Adapter 패키지:

    • JPA Adapter 패키지는 데이터베이스와의 상호작용을 담당하며, Entity 클래스는 데이터베이스 테이블과 매핑되는 POJO(Plain Old Java Object)입니다. 이 패키지는 데이터베이스의 구현 세부 사항을 감추고, 도메인 모델이 데이터베이스 기술과 독립되도록 합니다.
  2. Domain → Model:

    • 도메인 모델은 비즈니스 로직을 담고 있으며, 비즈니스 이해관계자와 밀접하게 관련되어 있는 객체들로 구성됩니다. 이들은 엔티티와 다른 순수한 비즈니스 객체를 포함할 수 있습니다. 중요한 점은 도메인 모델은 외부의 구체적인 구현 기술에 영향을 받지 않도록 설계되어야 한다는 것입니다.

실무에서는 각 프로젝트의 특성에 따라 위의 구조가 다양하게 변형될 수 있습니다. 일부 프로젝트에서는 이러한 원칙을 조금 타협하여 도메인 모델 아래에 JPA 엔티티를 두기도 하지만, 원칙적으로는 엔티티와 도메인 모델을 구분하여 설계하는 것이 유지 보수성 측면에서 유리합니다.

아래 관련 질문 링크와 참고 자료를 함께 제공합니다:
- DTO 클래스의 위치에 대해 질문있습니다!
- 헥사고날 아키텍처에 대한 좀 더 깊이 있는 사례와 설명은 Domain Driven Hexagon에서 확인하실 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

개foot님의 프로필 이미지
개foot

작성한 질문수

질문하기