[메모 트리 프로젝트] 3. 설계 - 객체 모델링

프로젝트 글 목차

2021.03.13 - [메모 트리 프로젝트] 1. 기획

2021.03.13 - [메모 트리 프로젝트] 2. 설계 - 와이어프레임, 요구 사항

2021.03.14 - [메모 트리 프로젝트] 3. 설계 - 객체 모델링

2021.03.18 - [메모 트리 프로젝트] 4. UI 구현 - 1

2021.03.19 - [메모 트리 프로젝트] 5. UI 구현 - 2

2021.03.20 - [메모 트리 프로젝트] 6. 나머지 프론트엔드 작업

2021.03.20 - [메모 트리 프로젝트] 7. 배포 및 후기

---

객체 모델링

모델링에 있어서 가장 고민되는 부분은 사용자에 대한 처리였다.

하지만 로컬에서의 동작이 1차 목표였고, 이에 따라 사용자 처리는 부가적인 부분이니 사용자 값을 할당할 키 값만 고려하면 되지 않을까 라는 생각에 우선 아이템에 관한 부분만 설계했다.

 

폴더
- id
- 작성자
- 이름
- 공개 여부
- 상위 폴더 id

파일
- id
- 작성자
- 이름
- 내용
- 공개 여부
- 상위 폴더 id

↓

아이템
- id
- 타입 : 폴더, 파일
- 작성자
- 이름
- 내용: 빈 값 허용
- 공개 여부
- 상위 폴더 id

처음에는 폴더, 파일을 각각 분리해서 구상했지만 대략적인 구조를 정리해보니 폴더와 파일은 유사한 느낌이라기 보다 아니라 같은 객체에서 타입이라는 키로 분류하면 되겠다는 생각이 들어 하나로 합치게 됐다.

 

다음으로 폰트의 색상, 아이콘 이미지의 색상 등 추가적인 요구 사항을 고려했다.

그리고 mongoDB의 Document 형태로 정리하는 과정에서 아이템은 하위의 모든 아이템(childs)를 가질 수 있게

Embedded 형태로 구조를 정리했다.

 

{
  _id: ...,
  type: 'folder' // or file
  author: '*', // * = 전체 접근 허용
  name: ...,
  content: '',
  parent: ..., // 상위 폴더 id 
  childs: [
   Object Item A,
   Object Item B,
   ...
  ],
  
  // 추가 기능
  status: 0, // 0 = 비공개, 1 = 공개  
  color: '', // 기본 #000
  icon_color: '', // 기본 #000
}

 

물론 실제 구현 과정에서는 많은 변화가 있을 거 같다.

먼저 mongoDB를 겉으로만 훑어봤다는 점?

그렇기 때문에 지금 이 프로젝트의 Document 구조가 Embedded와 Linked 중 어느 구조가 적합할 지 명확한 확신이 들지 않는다. 물론 가볍게 구현하는 토이 프로젝트인 만큼 그냥 구현하더라도 별다른 문제는 생기지 않을 거 같으므로 처음 생각한 그대로 갈 확률이 높긴 할 거 같은 느낌?

 

아마 이 구조가 변경된다면, 읽는 방식으로 인해 변경이 생기지 않을까 싶다.

현재는 한 번에 모든 아이템을 조회하는 방식을 생각하고 있기 때문에 _id에 해당하는 객체만 가져오면 되지만

만약 depth 단위로 차근 차근 조회하는 방식이라면 Linked 구조가 적합하지 않을까 하는 생각이 든다.

또한, Embedded 구조라면 굳이 상위 폴더의 id 값과 자신의 _id를 가지고 있기보다 최상위에 id가 존재하고, 이후 자식 객체들은 굳이 id를 가질 이유가 있을까?

그리고, 추가 기능 부분에서 추가적인 값들이 더 필요하지 않을까?

배치 순서를 변경한다면? 이 순서를 기억하기 위한 정렬 관련 index 값이 필요하지 않을까?

 

이러한 부분들은 개발 과정에서 다듬어보려한다.

어쨌든 대략적인 모델링이 잡혔으니 다음 단계인 UI 구현으로 바로 이동!

부족한 부분은 추가적인 수정 후 회고에 정리해 볼 생각이다.