Replies: 2 comments 3 replies
-
지금의 UseCase를 가져오는 방식이 아닌 adapter 계층으로 옮기자는 말씀이 맞으실까요?
검증이 필요하다면 StudyMember 도메인에 요청하도록 구현하도록하는 것은 제한되는 상황인건가요? 그리고 중복코드를 줄이면서 의존성도 줄일 수 있다면 더 좋겠지만 둘 중 하나 선택해야 하는 상황이라면 저는 의존성을 줄이는게 아키텍처의 목적에 더 맞는 방식이라 생각합니다.
이것도 맞는 말씀이라고 생각합니다. 다만, api Path 같은 경우는 중첩 리소스라고 하더라도 애매하다고 생각합니다. 예를 들어 입출금 서비스와 계좌 서비스가 있다고 가정했을때 계좌 관리 서비스가 안된다고 입출금 서비스도 같이 안되면 곤란할 수 있다고 생각합니다. 그래서 각 서비스가 독립적으로 실행될 수 있느냐가 판단의 기준이 되면 더 좋을 것 같습니다.
검증 로직이 많이 생긴다는 것에 대해 예시가 있으면 좋을 것 같다는 생각이듭니다. 개인적으로는 2번, 3번 중에 하나가 나은것 같습니다. |
Beta Was this translation helpful? Give feedback.
-
답장을 읽다보니 생각의 전제가 다른 것 같다는 생각이 들었습니다.
위의 제가 말씀드린 전제에 따라 Study의 infra의 Client 구현체에서 StudyMember의 webAdapter에 있는 코드를 호출하는 방식으로 생각했습니다. (api 형식)
Study 도메인에 따로 StudyMember를 구현하는 것일까요 아니면 기존의 StudyMember의 도메인 기능을 사용하는 것일까요?
의존성을 줄인다는 의미가 변경으로써 생성되는 여러개의 클래스를 주입하게 되어 의존성이 늘어나는 것이 문제라고 보시는 걸까요? 아니라면 부연설명을 부탁 드립니다.
StudyMember는 Study의 id만 있어도 전반적인 기능이 독립적으로 실행 가능할 것이라 생각되지만, Study는 StudyMember의 기능이 필요한 경우가 많은 것 같습니다. 아래 후술하겠습니다.
검증 로직의 예시는 스터디를 삭제할 때 스터디 멤버의 관리자 여부를 검사하기 / 스터디 상세 조회 시 포도알을 보냈는지 검사하고 안보냈으면 팝업 띄우는 플래그 / 해당 멤버가 스터디의 멤버인지 확인하기 등이 있습니다. 스터디 조회 -> 스터디 멤버 List 읽기는 사실 여기 적긴했지만 굳이 스터디 조회할 때 멤버를 조회하지 않아도 될 것 같습니다. 그냥 StudyMember에 직접 쿼리하는게 효율면에서도 좋을 것 같습니다. 추가적으로 어떻게 생각하시는지 의견을 여쭙고 싶습니다! |
Beta Was this translation helpful? Give feedback.
-
이번에 Study 도메인 패키지 내부에서 StudyMember의 기능을 사용하려고 하면서 어떤 방식으로 다른 도메인의 기능을 사용할 지에 대해 고민하며 몇 가지 방법을 시도해보았습니다.
같은 프로젝트지만 헥사고날 아키텍처를 구현하다 보니 결정하기 어려운 부분이 있었습니다.
1. Study에서 StudyMember에 rest api 통신 (사실상 web adapter 사용)
2. Study에 따로 StudyMember Entity를 만들어 정보를 가져옴
3. Study와 StudyMember 합치기
지금 제일 유력하게 생각하고 있는 방향
ex) 스터디에 소속되는지, 관리자인지, 포도알을 보냈는지 여부 확인 등
이후 검증 로직이 많이 생길텐데 그때마다 중복되는 메서드를 만드는 것보다는 Study 도메인에 List로 StudyMember 도메인을 넣고 (LazyFetch) 필요할때마다 가져오는 것은 어떨까요?
1, 2번은 구현해봤는데 각자 장단점이 있는 것 같습니다. 편하게 의견 주시면 감사하겠습니다!
Beta Was this translation helpful? Give feedback.
All reactions