[42GG] 데이터 플로우 다이어그램 작성

 

데이터 플로우

프로젝트를 진행하면서 분석/설계가 미흡하다는 것을 느꼈습니다. 대회와 팀 관련 로직에서 비즈니스 로직은 정리를 했지만, 대회와 팀 간에 데이터 플로우가 없어서 개발하는데 누락사항이 발생하거나, 비즈니스 로직을 코드에서 명확하게 표현하지 못하는 상황이 발생했습니다.

대부분 하나의 엔티티에서 발생하는 변경에 대해서는 잘 구현이 되었지만, 하나의 기능에 여러 엔티티의 값을 변경하는 로직에서 이런 실수들이 발생했습니다. 예를 들어서 대회가 취소되는 경우 참가 신청했던 모든 팀의 인원들의 티켓을 환불하는 로직, 대회가 시작했을 때 확정이 안된 팀들에 대해서 참가 취소 및 환불 처리 로직 등이 있습니다.

또한 비즈니스 요구사항이 계속 바뀌면서 커뮤니케이션이 힘들어졌습니다. 해당 기능을 구현하는 사람은 변경된 요구사항을 온전히 이해하고 구현하고 있지만, 다른 기능을 맡고 계신 분은 변경 전 요구사항으로 생각하고 구현하는 등의 문제가 발생했었습니다.

오늘 회의 결과 대회 상태에 대한 enum(AgendaStatus)을 변경하기로 결정하면서, 이번 기회에 간단하게 데이터 플로우를 정리해야겠다고 생각했습니다.
 

 
아직 DFD 표현법에 익숙하지 않아서 일단 기능은 타원, 엔티티는 네모, 변경되는 데이터는 화살표 위에 표시하고 분기는 마름모로 표시했습니다. 원래는 대회, 팀, 프로필, 팀_프로필 중간테이블 등 엔티티를 더 추가해야하지만, 이번에 대회 관련된 리펙토링에 필요한 부분만 정리했습니다.

유저 플로우

추가로 티켓 관련해서 발급 및 사용 로직의 경우에는 데이터 플로우는 간단하지만 발급, 발급 실패 등 비즈니스적인 요구사항 자체가 복잡해서 유저 플로우로 정리했습니다. 하지만 기능별로 분기점이 많아서 데이터 플로우까지 정리해보면 좋을 것 같습니다.
 

• 티켓 발급 및 대회 참가 사용자 플로우

 

• 티켓 발급 실패

 

• 대회 취소되는 경우

 

정리

이번에 분석/설계가 부족한 이유는 API 명세 회의를 오래 진행하면서 기능에 대해 전부 다 이해했다는 착각을 했었던 것같습니다. 지난번 Open-RMF 프로젝트에서도 느꼈지만, 문서화가 부족하면 커뮤티케이션에 혼란이 오는 것 같습니다. 특히 유저 플로우나 데이터 플로우 같은 분석/설계가 미흡한 경우 실제 구현에서도 누락사항이 발생하는 것 같습니다. 조금 귀찮더라도 명확한 분석/설계 및 문서화 프로세스를 만들어야할 거 것 같습니다.