Skip to content

06 ‐ 11 ‐ DnD DnD Widget 모듈(MongoDB)

Jump to bottom
Ryu(Paul) edited this page Dec 31, 2023 · 4 revisions

모듈 설계서

모듈 설계서의 목적

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

모듈 설계서 구성요소

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

모듈 설계서 주의사항

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

DnD 모듈(MongoDB)

목차

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

비즈니스 요구사항

목적

  • 팀 페이지에서 사용되는 DnD UI, UX 를 위한 CRUD를 위한 용도로 구성되어 있다.
  • 해당 UI 에 내부 위젯을 위한 서브 비즈니스 로직을 가지고 있다.

요구사항

기능명세

  • (메인 기능) DnD파일을 MongoDB 에 Create, Read, Update, Delete
  • (서브) DnD 위젯 중 공지사항, 게시판을 위한 위젯의 요구를 받고 Read 기능을 수행한다.
  • (서브) DnD 위젯 중 캘린더 위젯의 요구를 받고 알림을 예약하는 기능을 수행한다.
  • (서브) 아직 논의되지 않은 DnD 위젯 중 요구를 받고 기타 Read 기능을 수행한다.

성능명세

  • 딱히 기준은 미정

아키텍처 설계

모듈 구성

  1. DnD Controller : 기본적인 DnD의 CRUD api 를 담당함
  2. DnD Service : 기본적인 DnD CRUD의 비즈니스 로직을 담당함.
  3. TeamDnD Repository : team 페이지의 DnD UI 저장소
  4. PeerLogDnD epository : Pearlog 페이지의 DnD UI 저장소
  5. DnD Sub Controller : DnD의 위젯의 api 를 담당함.
  6. DnD Sub Serivce : DnD의 위젯의 비즈니스 로직을 담당함.

데이터 모델

  1. TeamDnD
// 해당 데이터 타입은 java 기반이지만, 프론트와의 연계를 고려하여 프론트 타입들을 기준으로 지정됨 
{
  "_id": ObjectId, // MongoDB용 key, 객체형키, 프론트엔드에서 고려하는 용이 아닌 DB 상에서 구분 역할
  "teamId": long, // 기존의 team Id
  "type": string, // "team", "peerlog"
  "createdAt": LocalDateTime,
  "updatedAt": LocalDateTime,
  "widgets": List<Widget>,
}
  1. Widget Data
widget: {
  "key": long, 
  "size": String, // L,M,S
  "grid": DataGrid, // 하단에 해당 객체 참고
  "updatedAt": LocalDateTime,
  "createdAt": LocalDateTime,
  "data": Json // 각 위젯에서 프론트엔드 개발자가 사용 가능한 Data 영역이다. 위젯들에서 저장해야할 값들을 저장하는 용도이다. 
}

3.DataGrid Data

{
  "x": long,
  "Y": long, 
  "w": long,
  "h": long,
}
  • 기본적으로 데이터는 1번 TeamDnD가 최종적으로 프론트가 사용하는 데이터 구조라고 보면 된다.
  • 위젯을 구성하는 방식은 다음과 같다.
    • 기본적인 전체적인 틀에 대한 meta 데이터는 최상위 객체에 데이터(TeamDnD)를 활용하면 된다.
    • 각 위젯들은 TeamDnD 객체의 array(또는 List) 형태이 widget 객체들을 통해 저장된다.
    • widget 객체는 객체 내부에도 위젯들의 공통 내용을 담고 있는 파트가 존재한다.(key, size, grid, type, createdAt, updatedAt)
    • 공통 내용을 담는 부분은 위젯에 대한 개별 정보들을 담고 있다고 보면 되며, 위젯 생성시 기본적으로 채워져야 할 값들이다.
    • 그러나 공통 내용 만으로 개별 위젯의 데이터를 구현해 낼 수 는 없다. 더불어 백엔드에서 무언가 지정되어야만 하는 구조로 하게 된다면 프론트엔드에서 개발에 제약이 발생한다. 이에 다양한 위젯을 개발할 수 있도록 구조화를 짤 필요가 있고, 개별 위젯들마다의 데이터를 담을 필요가 있다. 그렇기에 프론트엔드 개발자들을 위해 지정된 위젯마다의 고유 데이터를 지정할 수 있도록 만든 것이 json 타입의 data 타입이다.
    • 이용 핵심 방식은 다음과 같다.
      1. 위젯마다의 내용을 기록하기 위한 고유 데이터의 json 화
      2. TeamDnD 타입의 각 위젯의 Data 변수에 저장한다.
      3. team DnD 의 변화가 발생했을 시 이를 통으로 저장한다.
    • 이와 반대로 데이터 로딩이 이루어지게 된다면
      • Json으로 들어있는 데이터를, 타입을 기준으로 원하는 클래스, 내지는 인터페이스로 Json화 한 내용을 다시 풀어서 객체화하여 사용한다.
  • 이러한 내용을 기반으로 잠정적으로 제한하는 UX 적 추천 내용 및 간단한 QnA 내용은 아래와 같다.
    • 이러한 구조는 비효율적이지 않은가? : 위젯의 개수는 제한적이며, 보다 큰 데이터가 필요한 경우에는 기본적으로 api로 호출하므로, 그렇지 않은 경우의 위젯의 경우 큰 문제가 없습니다.
    • 저장을 할 경우마다 전체를 업데이트 하는 구조가 타당한가? : 백엔드 없이도 충분히 구현이 가능하도록 플랫폼으로써의 기능성이 중요시 되기 때문에 이러한 구조를 채택했음. 더불어 이미지를 비롯해 무거운 요소에 대해서는 따로 api로 제작이 가능하며, 내부에 저장하는 데이터들의 사이즈는 최대 100MB 까지이며, string 구조라는 것을 고려한다면, 특별히 문제시 되지 않음을 알 수 있다.

에러 처리 전략

  • 테스트중인 현재
    • 200 OK 와 함께, request body 에 DnD 데이터를 통으로 전달
  • 실제 구현 시
    • 204 No Content, 저장을 비롯한 모든 행위가 성공적일 때, GET 요청을 제외하곤 해당 답변으로 성공적으로 저장(삭제, 갱신)이 됨을 알려준다.

API 엔드포인트 설계

자세한 내용은 API 저장소를 참고할 것

Test api

  1. DnD Create : POST - /api/v1/temp/dnd/create
  2. DnD Read : GET - /api/v1/temp/dnd/read
  3. DnD Update : POST - /api/v1/temp/dnd/update
  4. DnD Delete : DELETE - /api/v1/temp/dnd/delete

기본 api

  1. DnD Create : POST - /api/v1/dnd-main/create
  2. DnD Read : GET - /api/v1/dnd-main/read
  3. DnD Update : POST - /api/v1/dnd-main/update
  4. DnD Delete : DELETE - /api/v1/dnd-main/delete

달력 위젯 api

  1. Get team Member List : GET - /api/v1/dnd-sub/calendar/team-list
  2. Set Alarm Event : POST - /api/v1/dnd-sub/calendar/set-alarm
  3. Delete Alarm Event : DELETE - /api/v1/dnd-sub/calendar/delete-alarm
  4. Update Alarm Event : POST - /api/v1/dnd-sub/calendar/update-alarm

게시판 위젯 api

  • 담당자들의 논의 후 결정

공지사랑 위젯 api

  • 담당자들 논의 후 최신화

그림 api

  1. Upload image
  2. Change image
  3. delete image
Clone this wiki locally