인프런 커뮤니티 질문&답변
작성한 질문수
MemberRegister가 Member 엔티티의 C/U/D 작업을 모두 담당하나요?
작성
·
171
·
수정됨
0
안녕하세요, 토비님.
현재 MemberRegister 인터페이스는 register 뿐만 아니라 활성화/비활성화, 정보 업데이트 등의 오퍼레이션을 제공하고 있는데요,
해당 인터페이스에 작성된 주석은 회원의 등록과 관련된 기능을 제공한다여서 'register를 제외한 오퍼레이션은 다른 인터페이스에 위치해야 하지 않나?' 하는 생각이 듭니다.
혹은 회원 등록 외 오퍼레이션이 해당 인터페이스에 존재하는게 의도하신 바지만, 주석 내용이 수정되지 않은 걸까요?
궁금한 점을 요약해서 정리하자면, xxxFinder는 조회와 관련된 오퍼레이션을, xxxRegister는 생성/수정/삭제와 관련된 오퍼레이션을 가지는 걸까요?
완강 후 회사에서 강의로 알려주신 것들을 이것저것 적용해보며 재밌게 일하고 있습니다, 정말 감사드립니다.
답변 2
1
강의에서 잠깐 언급하긴 했는데, 회원 등록을 최초 회원이 되는 것을 포함해서 등록과 관련된 이후의 상태 변경 절차를 모두 포함하는 것으로 일단 정의를 했기 때문에 하나의 인터페이스 담았습니다. 등록이라는 의도로 정해지는 상태와 이에 연결되는 것을 등록이라고 생각하기로 했기 때문이죠.
이후에 이 작업이 복잡해지고 의도를 세분화하는 필요가 생긴다면 그때 분리할 수도 있습니다.
Finder, Register를 그런 의미의 접미사로 일단 정의해봤는데, 이후 다른 애플리케이션을 추가하면서 더 나은 이름이 있으면 그때 리팩터링 할 수 있습니다. 더 나은 일관되고 의도가 잘 드러나는 이름이 발견되면 그걸로 변경할 수 있습니다.
0
안녕하세요, 인프런 AI 인턴입니다. 대흉근님, 질문해주셔서 감사합니다.
토비님의 강의에서 헥사고날 아키텍처와 도메인 모델 패턴을 적용한 설계 방법에 대해 배우셨을텐데요, 여기서는 도메인 계층과 애플리케이션 계층을 어떻게 분리하고 역할을 나눌 것인가에 대한 전략이 중요합니다.
MemberRegister와 MemberFinder의 역할
MemberRegister 인터페이스: 주로 ‘회원의 등록’에 관련된 기능을 제공하는 것으로 보입니다. 여기에는 회원의 생성(Create), 수정(Update), 삭제(Delete) 작업을 포함할 수 있습니다. 하지만, 각 작업이 너무 다르거나 복잡할 경우에는 이들을 별도의 서비스로 분리하는 것도 고려할 수 있습니다.
MemberFinder 인터페이스: 회원에 대한 조회(Read)와 관련된 오퍼레이션을 담당합니다. 주로 회원 정보를 검색하고 조회하는 기능이 포함될 것입니다.
적절한 설계 철학
명확한 역할 분리: 인터페이스를 설계할 때, 각 인터페이스가 명확한 역할을 가질 수 있도록 구성하는 것이 중요합니다. 즉, MemberRegister는 회원의 ‘상태 변화’ (생성, 수정, 삭제)를, MemberFinder는 회원의 ‘정보 접근’ (조회)을 담당할 수 있도록 구성할 수 있습니다.
인터페이스의 명명과 주석: 인터페이스의 이름과 주석은 해당 인터페이스가 제공하는 기능을 명확히 설명해야 합니다. 이를 통해 개발자가 인터페이스의 기능을 쉽게 이해할 수 있습니다.
관련 논의에 대한 추가 자료로는 토비님의 강의에서의 MemberRegister와 MemberFinder에 대한 설명을 참고하여 명확한 역할 분리에 대해 확인해 보실 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
아, 말씀해주시니 어렴풋이 기억나네요, 재수강해야 할 때인가 봅니다.
오늘 인프런 밋업 끝마치시고 고되셨을텐데 늦은 시각에도 친절한 답변 감사드립니다.
좋은 밤 되세요!