Skip to content

06 ‐ 10 ‐ 소켓 모듈

Jump to bottom
Ryu(Paul) edited this page Nov 9, 2023 · 1 revision

모듈 설계서

모듈 설계서의 목적

  • 각 기능을 주관하는 모듈, 모듈의 형태나 로직은 변할 수 있고 수정이 될 수도 있다.
  • 하지만 기본적인 형태에 대한 확정은 개발에 있어서 아주 핵심적인 역할을 한다.
    1. 개발의 확신을 만들어준다. 담당이 된 사람들이 그 설계에 대해 주도권을 쥐는 만큼 개발 과정의 불확실함보단 확실함으로 진행이 가능하다.
    2. 타인의 개입이 가능해진다. 구조를 다른사람이 알 수 없다면, 피드백, 검토 하는 면에 있어서 개발의 주도권을 가진 당사자의 공개 여부에 따라 진행할 수 밖에 없다. 하지만 확정된 로직이 어느정도 밖에 나와 있다면, 동료들의 적극적인 리뷰와 개입으로 오류를 최소화 할 수 있다.
    3. 버스팩터(Bus Factor)를 줄여준다. 개발 과정에서 부득불 생기는 문제로 현재 개발자가 개발을 이어가지 못할 때, 인수인계의 준비조차 어려운 상황이라면 이를 통해 단편적으로나마 현재의 코드를 이해하고 개발을 이어갈 수 있다.
    4. 개발자 스스로 머릿속에서만 정리된 구조가 현실화가 될 수 있는지 점검이 가능하다. 머릿속, 사고적으로 구성된 구조는 모순이나 오류가 많다. 특히 오류가 발생하는 순간이 언제인지 설명하는 순간이 아닌 이상 논리적 오류나, 구성 면에서의 오류는 발견하기 어렵다.
  • 위 처럼, 모듈 설계에 대한 문서화는 개발의 핵심 요소이므로, 담당으로 맡은 사람이 구현을 위해 이해하는 것이 중요하다.

모듈 설계서 구성요소

  1. 비즈니스 요구사항
    • 모듈의 근본적인 목적, 요구사항 등을 기재하여 요구되는데로 설계가 되었는지를 명확히 한다.
  2. 아키텍처 설계
    • 모듈의 아키텍처 설계의 명확성을 높이고, 담당 개발자가 구체적인 지침으로써 이를 활용할 수 있다.
  3. API 엔드 포인트 설계
    • 필요한 기능을 수행하기 위한 엔드포인트로 프론트엔드 개발자들과의 협업을 개선한다.
  4. 다른 모듈과 상호작용 포인트
    • 의존성 관리에 포함되는 영역이지만, 설계 및 요구사항의 맞춰 기능 구현을 하려고 보면 개발자들끼리의 협의 내지는 논의가 필요할 수 있다. 이를 사전에 논의할 주제로 띄워 놓는 역할을 하며 상호 소통 전에 이를 인지하고 상호 모듈을 고려한 설계를 할 수 있게 만들어 준다.

모듈 설계서 주의사항

  1. 명확성 : 설계 문서는 여러 사람이 봐야 하니, 사용되는 용어나 개념의 명확한 정의를 분명히 해야 한다. 특히 기능정의서 사용된 단어들은 '바꾸지 말고 그대로' 사용할 것! 기획이 바뀌어 용어가 바뀌지 않는 이상 바꾸면 안되며, 기술적 용어들도 가능하면 풀어 쓰거나, 배제하면 좋다.
  2. 유지보수성 : 문서의 버전관리가 용이한게 중요하다. 본인이 설계한 내용이 변경이 필요할 때는 반드시 기존 내용은 백업을 해두고, 새로운 버전으로 만들어 문서를 관리함이 핵심이다.
  3. 협업을 고려한 구성 : 해당 문서는 기본적으로 협업을 고려해야 한다. 문장이 깔끔한지, 명확하게 정리가 되어있는지, 상대방이 읽기 쉬운 구조로 짰는지 한번 씩 체크할것!

예시 모듈 설계서

쪽지 모듈 아키텍처 문서

목차

  1. 비즈니스 요구사항
  2. 아키텍처 설계
  3. API 엔드포인트 설계
  4. 다른 모듈과 상호작용 포인트

비즈니스 요구사항

목적

  • 사용자 간의 쪽지를 주고 받는 REST 기능을 구현한다.

요구사항

기능명세

  • 사용자는 쪽지를 보낼 수 있다.
  • 사용자는 받은 쪽지를 확인할 수 있다.
  • 사용자는 받은 쪽지 리스트를 삭제 할 수 있다.
  • 사용자는 쪽지를 받을 수 있고, 받을 시 알람이 갈 수 있어야 한다(PWA로)
  • 자기 팀의 사용자들의 목록에 빠르게 접근 가능하다
  • 자기 팀의 사용자들의 목록에 접근한 이후, 선택을 통해 메시지를 전달한다.
  • 보낼 사람들의 목록에서 일부를 삭제할 수 있다.
  • 클라이언트의 요청에 따라 쪽지 리스트를 전달한다(무한 스크롤)

성능명세

  • 동접속자 수 XX 명 가능케 하기
  • 기타 등등 고려해봄직한 내용

아키텍처 설계

모듈 구성

  1. Controller : HTTP 요청을 처리한다.
  2. Service : 비즈니스 로직 수행
  3. Repository : 데이터 저장소와 상호작용을 담당한다.

데이터 모델

(ERD 참고할 것)

  1. messageIndex
    • id : 쪽지 탐색을 위한 자동 발급된 인덱스 고유값
    • userId : 쪽지를 보내는 당사자
    • opponentId : 쪽지를 수신하는 대상
  2. messagePiece
    • id : messageIndex의 값으로, 빠른 접근을 위한 구조
    • senderId : 메시지 발신한 사람을 확인하는 용도
    • messageTime : 쪽지가 발송된 시간으로, DB 저장과 함께 작성된다.
    • readTime : 상대쪽에서 API 요청을 받게 되었을 때, 성공적으로 전송될 시 읽은 것으로 취하기 위함인 데이터. NULL 허용한다.
    • content : 쪽지 내용

에러 처리 전략

  • 특정 상황이나 기능 상 발생 가능한 것들이 있다면 자유롭게 적어주세요~

API 엔드포인트 설계

  1. 쪽지 보내기 : POST /profile/message/new-message
  2. 쪽지 수신하기 : GET /profile/message?target=${userId}
  3. 쪽지 목록 리스트 제공 : GET /profile/message?target=${userId}
  4. 쪽지 다중 보내기
  5. 쪽지 PWA 수신

다른 모듈과 상호작용 포인트

프로필 모듈

  • 상대방 프로필 탐색 메소드 필요

팀 모듈

  • 팀 참여자 ID 탐색 메소드 필요

알람 모듈

  • 알림 DB 쪽으로 쪽지 내용을 전달하기 위한 메소드 필요
Clone this wiki locally