인프런 커뮤니티 질문&답변
작성한 질문수
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
작성
·
14
1
안녕하세요 제미니님 유튜브랑 인프런 강의 잘 듣고 있습니다. 항상 감사합니다. 😃
다름이 아니라 강의를 보고 사이드 프로젝트를 해보고 있는데,
도메인과 엔티티를 분리해서 엔티티는 단순 DB 매핑용으로만 쓰고 모든 비즈니스 로직을 도메인에서 처리해보려 하고 있습니다.
그러다 보니 '수정'같은 경우(예를 들면 state를 예약에서 취소로 변경하는)에는 id로 엔티티를 찾고 도메인으로 매핑해서 도메인 내부에서 검증과 로직을 처리해야 하는데, 매핑하는 과정에서 수정하는 데 불필요한 List<같은 격벽 하위 도메인> 들도 다 조회를 해서 세팅을 해줘야 하더라구요.
1 : N 관계라 쿼리도 많이 나가게 되고 수정에 불필요한 필드들을 세팅하는 거라서 비효율적이라 생각해서 개선을 해보려 합니다.
강의 예제 코드에서는 단순 update는 entity 에서 처리하는 것 같던데, 저는 도메인과 엔티티 계층을 엄격히 분리해서 service 내에서 entity를 의존하는 것이 불가능한 상황입니다. 또한 비즈니스 로직도 엔티티가 아닌 도메인 내부에 놓고 싶습니다.
수정에 필요한 필드만 가지고 있는 수정용 도메인을 만들어서 처리할까 생각도 해보았는데, 비즈니스 로직이 흩어지는 것도 이상하고, 얕은 지식이지만 애그리거트 루트에서 데이터 변경이 이루어져야 한다는 생각이 있습니다.
그렇다고 도메인 내부의 하위 도메인 리스트를 nullable하게 가자니 제미니님이 OrderSummary 관련 강의 때 말씀하신 null을 허용하는 도메인을 웬만해서는 선호하지 않는다에 공감이 가서 고려를 안하고 있습니다.
조언을 주시면 정말 감사하겠습니다 ㅜ.ㅜ 😢
답변 2
0
안녕하세요 질문 감사드립니다!
의도적으로 훈련을 하고 계시는 군요 아주 멋집니다! 👍
계속 해보시면 느끼시겠지만 결국.. 모든 상황을 완벽히 만족시키는 방법은 없습니다😄
그래서 그 속에서 트레이드 오프를 생각해서 타협하여 전략을 결정하셔야합니다!
불필요한 리스트를 조회해서 채워주던가
nullable 을 허용하던가
수정에 대한 클래스를 만들던가
등등 몇몇 방법이 더 있을듯
저 또한 이에대해 각각 케이스별로 만들어보고 차이점을 느껴봤었기에 나름의 전략을 세웠습니다
우선 저는 nullable 허용을 안한다가 타협 없는 지점 입니다
그러면 이제 선택지가 좁혀지죠
Post
Comments
Images
이런 구조라 했을때 Post 를 가져올 때마다 Comments, Images 를 다 채워야한다면 비효율이 있는게 맞습니다
조회 영역을 타협하겠다면 Post가 Comment나 Image를 기본적으로 모르게하고 필요한 영역에서 조합하도록 사용할 수 있을 것 같습니다 (ex] Presentation Layer)
그치만 연관 개념들이 잘 모여있는 구조를 유지하고 하고싶고, 저 조합하는 전략이 싫다면 어쩔 수 없이 매번 채워야겠죠 😃 (강의에서도 유사한 구조가 몇 번 있었던 것 같습니다)
다음 전략 후보로는 수정에 대한 필드를 갖는 수정 개념 객체를 만든다 적어주셨는데
이것도 괜찮은 전략 중 하나입니다 대신 수정용 도메인 이런 느낌으로 접근하기 보다는 행위/책임 자체에 집중하여 클래스를 구성해서 구현해보시면 느낌이 꽤 다를 수 있습니다
Reservation, ModifyReservation 이렇게 가는 것 보다는 ReservationCancel 이런 행위가 나오는 것은 코드나 구조를 봤을 때 상당히 자연스러울 것 같습니다
아무래도 전체 코드나 도메인 특징을 제가 모르다보니 임의로 질문주신 내용 기반으로 답변을 드려봤습니다!
결국은 핵심은 매번 하나의 전략으로만 모두 통일할 필요는 없기 때문에 의도와 맥락과 흐름이 잘 들어가있으면 된다고 생각합니다 (어쩔땐 List 다 불러오게 했다가, 어디선 수정 클래스도 만들고)
여러모로 구현해보시고 장단점을 비교해보시고, 코드를 느껴보시고 상황에 맞춰 적절한 전략을 선택해보시는 것을 추천 드립니다!
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. 후후후후님.
도메인과 엔티티를 분리하여 각자의 역할에 맞게 로직을 구성하는 방법을 고민하고 계시군요. 이는 아키텍처 설계에서 비즈니스 로직과 데이터 접근을 분리하고자 하는 좋은 시도로 보입니다. 그러나 이러한 구조에서 발생하는 데이터 접근 최적화 문제는 많은 개발자들이 겪는 어려움 중 하나입니다.
도메인/엔티티 분리 상황에서의 쓰기 작업 처리 방안
값 객체(Value Object) 사용:
- 필요 시, 수정에 필요한 정보만을 담은 값 객체를 도메인 계층에서 생성한 후, 이를 엔티티에 적용하여 업데이트를 수행할 수 있습니다. 이를 통해, 비즈니스 로직을 도메인 계층에 유지하되, 엔티티의 변경을 효과적으로 처리할 수 있습니다.
- 필요 시, 수정에 필요한 정보만을 담은 값 객체를 도메인 계층에서 생성한 후, 이를 엔티티에 적용하여 업데이트를 수행할 수 있습니다. 이를 통해, 비즈니스 로직을 도메인 계층에 유지하되, 엔티티의 변경을 효과적으로 처리할 수 있습니다.
별도의 도메인 서비스 활용:
- 비즈니스 로직이 여러 애그리거트에 걸쳐있거나 애그리거트 내에서도 복잡한 경우, 별도의 도메인 서비스를 작성하여 로직을 처리해볼 수 있습니다. 이 서비스는 애그리거트 루트와 연동하여 데이터를 가져오고 수정 작업을 수행합니다. 서비스 계층에서 이 역할을 맡아주는 것이 좋습니다.
- 비즈니스 로직이 여러 애그리거트에 걸쳐있거나 애그리거트 내에서도 복잡한 경우, 별도의 도메인 서비스를 작성하여 로직을 처리해볼 수 있습니다. 이 서비스는 애그리거트 루트와 연동하여 데이터를 가져오고 수정 작업을 수행합니다. 서비스 계층에서 이 역할을 맡아주는 것이 좋습니다.
Aggregate 인터넷 사용 줄이기:
- 비즈니스 로직 적용 시, 필요한 정보만을 로딩하고, 필요 없는 데이터는 제외합니다. 이를 위해 Hibernate의 lazy loading을 적절히 활용하거나, JPQL이나 QueryDSL을 사용해 쿼리를 구체화하는 방법도 고려할 수 있습니다.
- 비즈니스 로직 적용 시, 필요한 정보만을 로딩하고, 필요 없는 데이터는 제외합니다. 이를 위해 Hibernate의 lazy loading을 적절히 활용하거나, JPQL이나 QueryDSL을 사용해 쿼리를 구체화하는 방법도 고려할 수 있습니다.
영속성 모델과 도메인 모델의 변환을 간소화:
- 엔티티와 도메인의 변환 작업이 지나치게 복잡하다면, 변환 로직을 간소화할 수 있는 방법을 모색해보세요. 불필요한 연관 관계를 제거하거나, 필요한 경우 Projection을 사용하여 쿼리 성능을 높일 수 있는 방법이 있습니다.
- 엔티티와 도메인의 변환 작업이 지나치게 복잡하다면, 변환 로직을 간소화할 수 있는 방법을 모색해보세요. 불필요한 연관 관계를 제거하거나, 필요한 경우 Projection을 사용하여 쿼리 성능을 높일 수 있는 방법이 있습니다.
관련 논의를 통해 더 많은 관점을 얻고 싶다면, 다음 질문들을 참고하세요:
- 서비스 레이어와 엔티티 모델 분리 고민
- 도메인과 엔티티 모델 간 차이를 명확히 이해하기
위의 방안을 통해, 도메인 모델은 비즈니스 로직을, 엔티티 모델은 데이터베이스 접근을 담당하며 서로 협력할 수 있도록 구조를 유지할 수 있습니다. 이러한 접근은 유지보수에 유리하며, 각 모델의 책임이 분명해 사용이 용이합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.