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

안녕하세요 질문 감사드립니다!

우선 여러가지 방법이 있지만 구조에 따라 선택 가능한 전략이 있을 것 같습니다!

적어주신 1번의 경우 현재 강의 구조에서는 Entity가 Domain 클래스를 알 수 없습니다! 그래서 불가능한 구조입니다

해당 방식을 쓰려면 domain 모듈을 추출해서 db-core->domain을 알게 해야하거나 / db-core가 core-api를 알야하는데요

일단 전자는 단순히 그 지저분함을 위해 작업하는게 타당한지 + 현재 우리 프로젝트의 상황 팀의 상황 등등을 봐야한다고 생각하고 후자는 배 보다 배꼽이 더 큰 의존성 문제가 있다고 봅니다!

지저분한 부분이 너무 크다고 느껴지면 현실적으로는 Mapper 클래스를 생성하거나, 각 도구 클래스에 적절하게 책임을 분산하는게 낫다고 생각합니다!

(제가 자바 쓴지가 좀 오래 되긴해서 최신 JDK에서는 뭔가 유용한 기능이 있지 않을까 싶네요)

추가로 질문해주신 내용에서는 저는 일반적으로 한가지 기준(도메인 객체를 쓸지 엔티티 객체를 겸용으로 쓸지)을 정합니다!

회사에서는 결국 공통된 규칙이 있지 않으면 혼돈이 올 수 있기 때문에 팀과 토론 후 한가지 전략을 정해서 진행하는 편입니다

개인적으로 진행하는 프로젝트의 경우는 효율(생산성, 변경용이 등) / 도메인이 내 머리속에 완벽해서 잘 만들기 쉽겠다 이런 항목들을 검토한 다음 구현 전략을 확정해서 가는 편입니다!

그래서 종합적으로는 대부분 시작하는 시점에 결정하고, 기존 레거시 프로젝트라면 기존 프로젝트 이해도를 잘 분석해보고 적절한 전략을 선택합니다!

만약 현재 프로젝트가 모호하다면, 그것 자체가 도메인이 정립이 잘 안되어있거나 각 도구 클래스들의 행위나 역할이나 책임이 제대로 구성되어 있지 않을 수 있습니다.

만약 그것에 대해 감이 아직 없다면, 일단은 Entity 와 개념 클래스(Domain)에 대해 너무 빡빡한 규칙을 적용하지 않고 어느정도 선을 넘게하여서 관망하는 것도 좋은 방법입니다!

가장 중요한건 지금 나의 프로젝트와 상황을 이해하는 것이라고 봅니다!

모쪼록 답이 되었길 바랍니다! 감사합니다!

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

귀하의 질문은 도메인 객체와 엔티티 객체의 변환 및 사용에 관한 고민으로서, 자바를 사용할 때의 코드 간결성 및 유지보수를 고려한 접근 방식에 대한 것입니다. 또한, 도메인 객체와 엔티티 객체의 구분 시점에 관한 질문인데요. 이 주제는 소프트웨어 설계와 코드 아키텍처의 핵심 부분입니다.

1. 엔티티 객체에서 도메인 객체로 변환하는 방식

방법 1: 엔티티 객체에 변환 메서드 생성

• 설명: toDomain()과 같은 메서드를 엔티티 객체에 생성하여 도메인 객체를 반환하게 하는 방식입니다. 엔티티 객체가 도메인 객체의 구조를 이해하고 있어야 하기 때문에 객체 간 의존성이 생깁니다.
  
• 장점: 간편한 접근, 메서드 체이닝 등으로 쉽게 변환 가능.
  
• 단점: 코드의 의존성이 커져 엔티티 객체가 도메인 로직을 지나치게 알고 있을 수 있습니다.
  

방법 2: 외부 Mapper 클래스 생성

• 설명: 데이터 접근 레이어에 Mapper 클래스를 두어 변환을 담당하게 만드는 방식입니다. 예를 들어, ProductMapper.toDomain(entity)와 같은 형태로.
  
• 장점: 객체 간의 역할이 명확해지고, 변환 로직이 필요한 곳(Mapper)에 응집됩니다.
  
• 단점: 변환될 객체가 계속 늘어나면 Mapper가 방대해질 수 있습니다.
  

2. 도메인 객체와 엔티티 객체의 분리 시점

• 설계 초기 결정: 프로젝트의 시작 시점에서 도메인과 엔티티를 명확히 구분하는 것은 각 객체의 역할을 명확히 하고, 코드의 응집성을 높이는 데 도움이 됩니다.

• 프로젝트 규모와 복잡도에 따른 유연성: 초기 설계에서 모든 것을 구분할 경우, 복잡도가 높은 프로젝트에서는 지나치게 많은 코드가 생길 수 있습니다. 따라서, 프로젝트의 일정, 팀의 역량, 요구사항의 변경 가능성 등을 고려해 유연하게 접근하는 것이 좋습니다.

주관 및 논리

• 주관적 선택의 중요성: 도메인 객체와 엔티티 객체의 구분은 결국 소프트웨어의 변경 용이성, 유지보수성에 영향을 미칩니다. 프로젝트의 지속적인 변경 사항이 예상될 경우, 객체를 분리하여 변화에 대한 저항력을 유지하는 것이 좋습니다.

• 팀 설득 논리: “도메인 객체를 사용함으로써 전체적인 코드의 읽기 쉬운 수준과 변경에 대한 안전성을 확보할 수 있다”는 점을 강조하는 것이 좋습니다. 또한, 객체의 변화가 독립적으로 이루어진다면 다른 부분에 영향 없이 수정이 용이할 수 있다는 점도 추가적인 설득 요소가 될 수 있습니다.

관련한 결정의 기준은 프로젝트 복잡도 및 유지보수 필요성에서 기인한다는 점을 팀에 설명하시면 논리가 설득력 있을 것입니다.

저는 질문자님의 이해를 돕고자 기존의 답변들에서 유사한 내용을 참고하여 설명을 드립니다. 이 답변이 만족스럽지 않을 수 있는 점 양해 부탁드리며, 추가적으로 궁금한 점이 있으시면 언제든지 이어서 질문해 주세요. 곧 지식공유자께서도 답변해 주실 것입니다. 🙏

관련해서 아래의 참고 내용을 확인해 보시기 바랍니다:
- 도메인 계층에서 Page 사용 질문
- 어떤 경우 도메인(개념) 객체를, 어떤 경우 JPA 엔티티를 활용하나요?

Tag: #코틀린 #백엔드 #소프트웨어설계 #도메인모델 #엔티티모델