search

Wake-up-together-TogetUp / togetup-server

AI를 활용한 커뮤니티 기반 미션 알람 서비스, TogetUp!
1 stars 1 forks source link

논의해볼 사항들 #142

Closed hye-on closed 2 months ago

hye-on commented 5 months ago

☀️설명

논의해볼 사항들과 반영해야 할 변경 사항들입니다.

☀️논의 사항

찬미

혜온

05AM commented 5 months ago

자잘하게 논의할 사항이 있는 것 같아 기술적인 문제인 command와 query에 관한 의견을 각자 코멘트로 정리한 후에 회의하는 건 어떨까요?

다른 의견들도 원하시면 정리해서 적어도 좋습니다!

hye-on commented 5 months ago

command와 query를 분리

cqrs패턴 자체가 command와 query를 분리하는 것인데 (낮은 수준에서는 폴더,더 높은 수준에서는 db, 사용 기술을 분리) command와 query폴더를 분리하지 않아야 하는 이유가 있는지 궁금합니다. command와 query를 분리하는 것이 패턴의 의도를 따르며 응집도를 높인다고 생각합니다.

(같이 스터디한 책의 레포에서도 command와 query를 폴더를 분리하며 설명하고 있습니다.) https://github.com/madvirus/ddd-start2

작업 방식

협업 방식에 대해 제안합니다. 당장 해야할 일을 이슈에 적고 진행하고 있지만, 앞으로 계획이 어떤지 동기화가 되지 않고 논의가 부족하다고 생각이 듭니다. 또한 너무 자율적이라 계획대로 진행이 안될 때도 있는 것 같고, 중요도에 따라서 일을 처리하지 못하는 아쉬움이 있습니다.

그래서 제가 제안하고 싶은 방식은 각각 맡은 도메인의 리팩토링은 그대로 진행하고 , 앞으로 2주 (회의가 2주 간격이라서)단위로 해야 할 일을 같이 논의한 후 분담하면 어떨까요?

ex) 알람 리팩토링 -> 찬미 oauth 리팩토링 -> 혜온

2주동안 할 일

n일 이상 리뷰 댓글 미확인 시

저희가 Dn룰을 최초 리뷰에만 적용하고 있다보니 그 후의 리뷰에 대해서 확인이 늦어지고 있습니다. 깃허브 알람이 잘 안울리신다고 하여 며칠기다리고 매번 카톡으로연락드리는 것이 에너지가 들어서 이 문제를 해결할 수 있는 방안을 논의하고 싶습니다.

제가 생각한 방안

  1. n일 이상 리뷰 댓글 미확인 시 수정, 머지할 수 있는 권한을 준다.
  2. 원래대로 리뷰에 댓글을 달면 카톡을 남긴다.
  3. 리뷰 댓글도 규칙을 정한다
    • ex) 1일 이내 보기 , 2일 이내 보기
05AM commented 5 months ago

저희 프로젝트는 JPA 엔티티와 도메인 모델이 한 클래스에 구현되어 있기 때문에 CQRS 패턴 적용시 패키지를 분리하는 것에 동의합니다.

하지만 모든 도메인 패키지에서 패키지를 분리하는 것 보다는 읽기, 쓰기 모델을 최적화하는 도메인에서만 분리한다면 좋을 것 같습니다.

읽기, 쓰기 모델이 분리되지 않은 상황에서 패키지만 나누는 것은 복잡도를 가중시켜 큰 이점이 없을 것 같습니다.

패키지 분리에 대한 제 의견은 이렇고, 의논하고 싶은 부분은 cqrs 패턴 적용시에 서비스명을 어떻게 할지 정하면 좋을 것 같습니다!

hye-on commented 5 months ago

패키지 분리에 대한 의견이 같았네요

차이가 나는 부분이 "읽기, 쓰기 모델을 최적화하는 도메인" 의 기준인 것 같아요 저는 커멘트 서비스 , 쿼리서비스가 있는 도메인이 패키지 분리가 되야한다고 생각했습니다.

아래 댓글로 남겨주신 "서비스의 기능을 구분한다는 의미" 로 쿼리서비스라고 하셨는데 어떤 기능을 구분하는지 궁금합니다. 또한 읽기 기능을 구분한다는 의미가 없는지, 있다면 command, query를 구분하는 것과 어떤 점이 다르다고 생각하셨는지 궁금합니다!

image

의논하고 싶은 부분은 cqrs 패턴 적용시에 서비스명을 어떻게 할지 정하면 좋을 것 같습니다

000커멘드 서비스, 000쿼리 서비스로 해도 좋을 것 같습니다!

05AM commented 5 months ago

cqrs 패턴에 대해 의견만 적고 회의에서 논의하려고 생각했는데, 글이 길어질 것 같아 코멘트로 먼저 정리해두겠습니다!

제 생각와 관련 글들을 종합하여 말씀드리자면 cqrs 패턴을 적용하는 이유는 쿼리와 커맨드 시에 다른 것을 사용하기 때문입니다.

예를 들어 jpa에서는 entity를 다르게 사용한다던지, query/command 패키지별로 db를 다르게 사용한다던지의 방법이 있을 것 같습니다.

그런데 쿼리와 커맨드의 실행에서 다른 점이 없는 도메인에 굳이 패키지를 나눌 필요는 없다고 생각합니다.

만일 저희가 단일 jpa 엔티티를 사용하고 있는 상황에서 query와 command로 패키지를 분리하고 각각 controller, service, domain을 정의한다면 해당 엔티티는 어디에 위치해야 할지 의문이 드는 것 같습니다.

그래서 저의 의견은 명확히 cqrs 패턴을 적용하여 query와 command 사이에 다르게 적용하고 있는 부분이 있는 도메인을 해당 구조로 패키지를 나눴으면 좋겠습니다!

그렇지 않은 상황에서 패키지만 나누는 것은 구조의 복잡도를 높이는 원인이 될 것 같습니다.