ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 모델 구조 설계는 데이터베이스 설계가 아닌 객체 설계 먼저
    Today I Learned 2022. 10. 30. 23:57

     

    모델 구조의 확장 시도

    어제 구현한 MVP를 기반으로 기능에 보여질 내용을 확장하기 위해 최초로 작성한 모델을 확장하기 시작했다.

     

    MVP는 게시글 목록만을 확인할 수 있는 아주 단순한 모양으로, 모델 역시 최소한의 객체만으로 이루어져 있었다. '게시글' 모델, '사용자' 모델이 존재했고, 게시글 모델은 id와 글 내용, 게시글에 등록된 사용자 리스트, 사용자 모델은 id와 이름, 사용자가 등록되어 있는 게시글 리스트만으로 이루어져 있었다.

     

    MVP의 확장은 두 단계에 걸쳐서 하려 했다.

    먼저 사용자, 게시글 모델 사이에 '운동 포지션' 모델을 추가할 계획이었다. 여러 포지션들이 게시글 하나에 속하는 구조를, 그리고 각 포지션에는 여러 명의 사용자가 속하고, 각 사용자도 여러 개의 포지션을 갖는 양방향으로 바라보는 구조를 갖게 하려 했다.

     

    그렇게 모델 간의 관계를 확립한 이후에 다른 모델에 종속되지 않는 데이터들을 각 모델들에 추가하고, 게시물 상세 내용을 조회하는 기능을 구현하려 했다.

     

     

    프론트엔드 컴포넌트의 테스트 코드를 작성하면서 의문점이 들기 시작했다. 일단 생각한 대로 게시글에 작성자를 추가하고, 운동 포지션을 추가해 운동 포지션의 간단한 정보와 참가자 정보를 갖고 있는 게시글 객체의 구조를 만들어보았다.

     

     

    그랬더니 객체 안에 배열을 갖는 요소가 있고, 그 배열의 요소는 객체인데 그 안에 또 배열이 있고, 배열의 요소가 또 객체를 갖는 굉장히 복잡해 보이는 구조가 도출되었다. 뭔가 잘못되었다는 생각이 들었다.

     

    두 가지 의문이 들었다. 먼저 게시물 객체를 굳이 저렇게 깊은 depth를 갖도록 구성하는 게 맞는가 하는 점이었다. 게시물 객체 하나에 모든 것들을 담기보다는 백엔드에서 게시물, 포지션, 사용자 정보를 각각 나눠서 받아오고, Store나 페이지 영역에서 이들을 조합해서 전달하면 더 효과적인 구조를 만들 수 있을 것 같았다.

     

    그리고 일단 이 모델 구조 자체가 정말 합리적인 구조가 맞는지도 의문이었다.

     

    동료분의 질문에 답해주시기 위해 노아 트레이너님이 오셨을 때 어떻게 설계를 해야 할지 질문했다. 노아님은 질문에 대한 답변보다도 먼저, 지금 설계되어 있는 양방향 다대 다 관계를 사용하지 말 것을 이야기하셨다. 가능하면 일대 다, 다대 일로 관계를 구성하고, 그를 위해 데이터 모델링보다도 객체들을 객체 지향적으로 설계를 먼저 다시 진행해볼 것을 제안하셨다. 눈물을 머금고 설계를 다시 진행해보기로 했다.

     

     

    모델 구조 재설계

    내 웹 애플리케이션에서 게시글의 목적은 운동을 하기 위한 사람들을 모아 팀을 짜는 것이다. 그러면 게시글로부터 '운동 팀'이라는 모델이 생겨날 수 있다.

     

    운동 팀은 여러 개의 모집 운동 포지션과 팀에 참가하는 멤버들을 알 수 있다. 그로부터 '운동 포지션'과 '운동 멤버'라는 모델이 생겨날 수 있다. 각 운동 포지션에도 마찬가지로 운동 팀에 참가하는 운동 멤버들이 속해 있다. 운동 멤버는 자신이 누구인지 알기 위해 사용자 모델을 참조할 수 있다.

     

    게시글 상세 보기 기능에서는 자리가 있는 포지션에 참가를 신청할 수 있다. 이때 신청은 '신청' 모델을 통해 이루어진다. 구체적인 동작을 아직 구상하지는 못했지만, 아마 사용자 정보를 이용해 멤버 생성을 요청하고, 전달받은 멤버를 팀과 포지션에 추가할 것을 요청하는 방식으로 이루어질 것으로 생각된다.

     

     

    구상을 바탕으로 정리해본 클래스 구조도는 다음과 같다. 객체의 동작이 정의되지 않았고, 실제 클래스 다이어그램과는 문법이 다르므로 가볍게 구조를 파악하는 느낌으로 보면 좋을 것이다.

     

     

    운동 게시글에 팀원을 모집하는 과정을 구체적으로 생각해보고 트레이너님의 도움을 받아 기존에 생각하지 못했던 모델들을 생각해내고 모델들의 관계를 재구성하니 다대 다 관계로 나타내야만 할 것 같았던 관계가 일대 다 관계로도 나타낼 수 있음이 보였다. 객체 설계가 먼저 잘 이루어질 경우 데이터 모델링은 그로부터 자연스럽게 따라올 수 있다고 했던 노아님의 말씀이 수긍이 갔다.

     

    새벽 별을 보면서, 떠오를 동녘을 기다리면서 설계한 모델 구조를 바탕으로 2차 구현을 진행해보도록 하자.

     

     

    읽어볼 것

    https://limkydev.tistory.com/77

    https://velog.io/@lychee/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-01.-%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84%EC%99%80-%EC%8A%A4%ED%94%84%EB%A7%81

     

     

     

    댓글

Designed by Tistory.