05 22(일) 온라인 회의

[JAWSP]

DDD(뗑컨아님)

• 도메인주도설계라고 한다
• MVC패턴이랑 비스므리하면서 다르다고 한다
• Layer별로 나뉜다고 한다
• 레이어는 유저인터페이스, 어플리케이션, 도메인, 인프라 스트럭쳐로 나뉘어진다

  • 유저 인터페이스가 MVC의 컨트롤러이고

    사용자에게 정보를 보여주거나 사용자의 요청을 하위레이어로

  • 어플리케이션은 MVC의 서비스역활

    어느걸 할지 명시만 한다고 한다

  • 도메인

    실제 동작은 여기서

  • 인프라스트럭쳐

    리포지토리역할을 한다고 한다

user의 리포지토리랑 서비스

• 리포지토리에 있는 유저를 수정하고 저장하는걸

  서비스쪽으로 옮기는게 낫지 않냐고 생각한다고 한다

→이는 typeorm에서 기본적으로 제공하는걸 쓴다고 한다

→그럼 저것도 typeorm에서 긁어온건가

• 만약에 리포지토리를 쓰지 않는다면 어떤식으로 할 수 있냐면
  • ORM에서 리포지토리를 가져와서 user에 대한 앤티티를 넣게 된다고 한다

- 이렇게 해서 ORM에 있는 메소드(save)를 골라서 저장을 시킨다고 한다
- 그냥 user.service으로 병합을 시키는건가보다

• 또한 리포지토리에 대하여 테스트 케이스가 필요하다고 한다

• 여러개중 Nest.js를 통하여 불러올때 리스트 통째로 보여주는데

  우리가 필요하는건 그 중 일부만 쓸건데, 그럼 일부분만 리턴해주는 리포지토리를 만드는게 필요하지 않느냐란 이야기가 있었음

• 하지만 굳이 커스텀하지 않아도 될 것 같다고 한다

  리포지토리는 가독성을 위해서 나눠야 하지 않을까 라고 생각한다고 한다

• 리포지토리가 없게 된다면 →확실히 빠르게 된다고 한다

• 근데 find A (다가져오는거)find B(일부만 가져오기)

  →이는 어느 URL따라 가져오는게 달라지는데, 그걸 하는게 정말 편했다고 한다

→그럼 리포지토리를 나눌꺼면 확실하게 정하고 나누자 이렇게 하는게 나을듯(find, save)

→그리고 비즈니스패턴은 따로 테스트.?

→그리고 기본적으로 제공되는 리포지토리를 테스트를 하지 않아도 될 것 같다고 한다

→그리고 커스텀해서 가져온 놈들만 테스트를 하면 될 것 같지 않냐고 한다

예외처리

https://jakekwak.gitbook.io/nestjs/overview/untitled

• Nest.Js exception filters가 있는데

  어디서든 예외처리를 받아주는게 있다고 해서

  굳이 컨트롤러에서만 필요하나

• 그럼 일단 서비스단에서 예외처리를 하는걸로

아키텍쳐 요약

https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html dto

user모듈에는 3개가 있다

• 컨트롤러

  • 라우팅이랑 서비스호출을 하는 역활

  • 그럼 컨트롤러가 받는 값을 검증(join할때 아이디,비밀번호에서 유효하지 않을 값일때 처리)을 컨트롤러에서 하는지 서비스에서 하는지

  • https://jakekwak.gitbook.io/nestjs/overview/pipes 그리고 파이프라는 미들웨어에서 걸리긴한데

    →한계가 있다고 하던데(숫자, 문자열은 ㄱㅊ은데)

    →요건 미니쉘에서의 파이프랑 ‘얼추‘ 비스므리하다고 한다

  • 그리고 여러 항목(5개가 들어왔는데 3개가 들어온경우)을 검중할 경우 dto에서 걸러지지 않는다고 한다는데

  →나중에 논의 하십시오

• 서비스

  • 비즈니스 로직을 위주로 담당을 하면 될듯하다고 한다

• (커스텀)리포지토리가 있다고 한다

  • 쿼리문만 담당?(DTO만 담당?)
  • 나중에 논의?

  이건..뭐야..

https://github.com/royib/clean-architecture-nestJS

• DTO는 엔티티랑 맞지 않을 경우 걸러주게 된다고 한다

https://tecoble.techcourse.co.kr/post/2021-04-25-dto-layer-scope/#:~:text=%EC%A0%95%EB%A6%AC%ED%95%B4%EB%B3%B4%EC%9E%90%EB%A9%B4%20DTO%EB%8A%94%20%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8,%EA%B0%84%20%EC%A0%84%EB%8B%AC%EC%9E%90%20%EC%97%AD%ED%95%A0%EC%9D%84%20%ED%95%A9%EB%8B%88%EB%8B%A4
→저기에 나와있는 그림대로 폴더를 구성하는게 깔쌈한 아키텍쳐라고 한다

→엄격히 분리시킨다고한다

엔티티랑 DTO

• 엔티티는 정보마다 구별을 하는데
• DTO는 구별을 안한다
• 아니면

→일단 이것도 다음 회의때 결정을 해봅시다

꼐임

• 로그를 찍을때, 이긴놈 진놈을 비어둠

  →플레이중일떄는 누가 이겼는지 졌는지 모르자나

• queuing에서 기다리다가 →매칭되어서 셋팅이 되고 → 게임룸으로 가서 게임이 시작되고

• 큐잉에서 선착순으로 2명 되면 그대로 시작

• set rule이란 이벤트를 때리고 준비가 서로 되면

• 인터벌을 줘서 게임데이터랑 스코어이란 이벤트를 계속 클라이언트에게 주고

• 바 컨트롤을 서버에다가 보내줌

→그리고 요런 과정은 계속 이벤트를 던지고 받고 해주는건가봄

• 그리고 방같은 경우에는 방 id를 만들어서

→그리고 요 모듈에서는 api요청 받을때만 쓰임(response, request)

→소켓 통신할떄만 게이트웨이를 쓰는건가봄

→네임스페이스를 이용하여 나누면 멀티플랙싱이 되긴한데

채팅의 디렉토리를 나누는 것에 관하여

https://codevkr.tistory.com/58?category=719250 -?

채팅 서비스에선 이렇

그 외

• 채팅은 직접 짜봐야 알듯

• 그리고 게임갔다 채팅갔다 소켓갔다 와리가리하는게 정신없으니

  일단 하나 후딱 끝내고 하는게 낫다고 합의