도메인 주도 설계 경험 공유(중간 단계, 아직 미완성)

경험치 공유.

• 원래는 다 완성하고서 공유하려고 그랬는데, 글쓰기가 계속 늦어져서… 일단 쓰고 봅니다.
• 제가 최근에 참여한 사이드 프로젝트에서 기존에 설계에 대한 문서가 전무했던 상황이라 모델링부터 다시해야겠다고 생각했고, 제 나름대로 좀 잘 만들고 싶은 마음에 설계부터 해보기로 했습니다.
• 그래서 저는 UseCase Diagram, ERD(DBMS), ERD(DDD), api 목록, 화면 아이디 체크리스트를 만들게 되었고, 중간에 이런 자료를 참고했는데 이런 것도 도움이 되었습니다.(카카오의 ㄷㄷㄷ 영상을 참고했습니다.)
• 일부 캡쳐 본을 공유합니다.
• 프로젝트의 지난 회의에서 기존의 기능을 살리는 것에 대해서 이야기했어서 이 작업물이 안쓰일 가능성도 있지만, 도메인 주도 개발 중 설계를 맛봤다? 라고 평가할 수 있을듯합니다.

캡처 1 figma 기획의 화면을 따라가며 필요한 기능과 정보를 식별함.

캡쳐 2 useCaseDigram으로 기능을 식별함.

캡쳐 3 기능으로 도메인을 식별

캡쳐 4 도메인의 연관 관계를 그린 context Map

캡쳐 5 데이터를 식별하기 위해 그렸던 RDBMS ERD

• 그중에서 제가 느낀 것을 공유하려 합니다.

제가 작업을 하면서 느낀 것.

1. 무조건인 정답은 없다. 제가 읽었던 이 책(도메인 주도 개발 시작하기)에도 나와 있지만, 도메인 주도 개발을 항상 적용해야하는 것은 아니라고 합니다.
2. 무엇이든 도움이 되었다. 제가 위 캡쳐본(useCaseDiagram)에서 명시한 것처럼 useCaseDiagram을 그리고 나니, 아 도메인은 이렇게 나눌수 있겠구나? 이런 게 보이기 시작했습니다. 유즈케이스 다이어그램을 그리고 도메인을 구분하고, contextMap을 그리는 것도 괜찮은 방법일듯 합니다.
3. 좀더 경험치를 쌓자. 제가 작업한 순서는 피그마에서 화면을 찾는다. -> 화면에서 필요한 데이터 항목을 적어본다.(도메인 ERD 추가) 어떤 기능을 추가할지 유즈케이스를 추가한다. -> 데이터와 행위를 전부 찾았으면, 화면 체크리스트에 이 화면을 봤다고 체크한다.(플러스 이 화면에서 필요한 APi 가 있다면 같이 명시)-> 모든 화면을 순회할때 까지 처음으로 돌아가서 반복.

했었는데, 도메인 ERD를 그려야하는데 계속 RDBMS의 ERD를 그리게 되었습니다. 습관은 이기기 어려웠습니다. 하지만 절대적인 방법은 없다고 생각하니, 데이터를 먼저 생각해보고, Domain ERD를 그려보고 그 둘을 비교하면서, 서로를 조정하는 방향도 괜찮겠다 생각을 했었습니다.

• 보기 좋게 ERD는 그리는 작업은 차후 하기로 하였습니다. 지금은 아름다움 보다는 빠르게 작성하고 빠르게 수정하기 좋게 편집하는 것이 중요하다고 생각했습니다.
• 정말 유익한 경험이였고, 앞으로의 소프트웨어 개발시에도 보다 유연한 사고를 하면서, 설계에 좀 더 잘해서 협업하기 좋은 코드, 설계하기 좋은 코드를 개발해나가고 싶다는 생각을 했습니다.