설계 개요
3학년 때 소프트웨어공학에 대해 관한 수업을 들은 적이 있습니다.
당시 수업에서 교수님이 프로세스에 관한 내용을 강조 하셨고, 초기 설계의 중요성에 대해 동감했습니다.
그래서 프로젝트 초반 철저한 설계를 통해 추후에 발생할 오버헤드를 줄이기 위해 ERD를 작성하기로 했습니다.
아래의 다이어그램이 당시 작성한 다이어그램입니다.
초기 다이어그램
자바 클래스 설계
DB 테이블 설계
회고
아쉬운 점
-
초기본과 완성본 간의 차이
위의 다이어그램을 기반으로 도메인을 만들기 시작했지만, 추후 여러 기능을 추가하면서 도메인을 여러 차례 수정했습니다.
대표적으로 알림 기능을 구현하기 위한 도메인을 Notice 하나로 설계했었지만, 알림의 주체별로 구분할 필요가 있었습니다.수정 예시
- child → parent : Notice (아이의 위치 별 알림 & 아이가 직접 위험 상황임을 알림)
- helper → parent : Confirm (헬퍼가 보내는 도착, 출발, 미확인 등의 알림)
- parent → child 주변 member : Emergency (아이 주변의 멤버들에게 부모가 보내는 알림)
-
DB 테이블 설계
또, DB 테이블에 대한 다이어그램을 따로 작성했지만 Spring Data JPA(구현체 Hibernate)를 사용했고, 초기 로컬에서 개발 시에 ddl-auto : update 설정으로 시작 했기 때문에 DB 테이블을 굳이 짜지 않아도 됐었습니다.
잘한 점
-
가이드라인
작성한 다이어그램이 코딩 시 가이드라인이 되어서 조금 편하게 코딩을 진행할 수 있었습니다.
개발 초반에는 프로젝트 전체 관점과 세부 기능의 관점을 왔다갔다 하면서 코딩을 하다보니 정신을 잠깐 놓으면 헷갈리고, 길을 잃을 때도 있습니다.
하지만 이렇게 문서화한 자료를 두고 코딩을 하니 그럴 일이 없었습니다. -
소통
또, 팀플의 특성상 소통을 해야 하는 일이 많고, 정확한 의견 교환이 어려울 수 있습니다.
하지만 문서를 통해 소통하니 의사 표현이 훨씬 편했습니다.
마무리
다음 프로젝트에서도 시작 전 도메인 설계를 통해 프로젝트의 가이드라인을 잡는 절차를 거칠 것입니다. 하지만 DB 설계와 도메인 설계를 구분하지 않고 빠르게 끝낼 것입니다.
또, 수정을 막을 수는 없으니 MVP 도메인으로 만들긴 하지만, 최대한 기능을 꼼꼼히 분석해서 수정을 최소화 할 것입니다.
코드 깃허브
