백엔드 협업 프로젝트 초반 진행

사실은 화면이 제일 먼저입니다. 그리고 나서 데이터를 설계하죠. 생각보다 api는 변경의 여지가 많습니다. 다른 분들이 말씀하시듯 데이터베이스는 개발 초기에 생각보다 자주 바뀌지만, 그럼에도 불구하고 생각보다 api 설계만큼은 아니라고 봅니다. 직접 말씀하셨듯이 DTO와 ERD는 같을 필요가 없죠. 그 말은 하나의 테이블에 대해서 DTO가 얼마나 나올 지 아무도 모른다는 겁니다. 접근 방법이 다양하게 있지만 저는 보통 유즈케이스에 대한 분석부터 진행합니다. 개발에 대한 설계는 가장 마지막 단계고 제일 먼저 해야 할 건 애플리케이션의 유즈케이스가 어떤 흐름인지 명확히 하는 것입니다. 데이터베이스는 그 다음 문제죠. 당장 유저가 어떤 화면에서 무엇을 볼 지, 어떤 행동을 할 지도 명확하지 않은데 데이터베이스나 api 먼저 고민 해 봐야 결국 바꿔야합니다. 실무에선 기획자가 있겠지만 지금은 없죠. 개발자가 기획을 해야 합니다. 다행히 기능은 그렇게 많지 않습니다. 우선 와이어프레임부터 그리세요. 툴이 뭐가되었든 상관없습니다. 그냥 노트에 펜으로 작업하셔도 알아만 볼 수 있으면 됩니다. 그 후 목업페이지 부터 개발 합니다. 이미 기술은 정해졌단 가정이지만, 기술이 정해진 게 아니라면 백엔드 상관없이 프론트엔드부터 확실히 정하시길 바랍니다. (리액트든 뷰든 빌드하면 결국 html css js입니다. 백엔드 애플리케이션 빌드할 때 그 빌드 결과물 활용하면 굳이 분리해서 배포 할 필요가 없습니다.) 그 다음 데이터베이스를 설계하고 api 명세 및 Request parameter나 Response data (dto로 통합하기도 하지만 전 가능하면 dto와 vo는 구별하자 주의입니다. 로직에 쓰일 것인 지, 데이터 전달만 하고 사라질 것인 지 구별은 필요하다 생각해요.) 명세를 진행하는 흐름으로 진행하면 도움이 될 것 같네요. 협업의 핵심은 팀원과 소통을 통해 팀원들이 같은 목표를 바라보게 하는 것 아닐까요? 앞서 말씀드린 명세가 명확하지 않다면 팀원 모두가 각자 다른 일을 하는 불상사가 생길 수 있지요.

안녕하세요! 저 같은 경우는 프로젝트를 들어갈 때 아래의 순서로 진행합니다. 1. 보일러 플레이팅 기획서와 전체적인 기능 Flow가 나온 상태라면 ERD를 작업하고, API 리스트업 등을 먼저 하겠지만 보통 프로젝트가 그렇진 않더라고요 2. ERD 설계 백엔드는 클라이언트에게 필요한 데이터를 작업하는 과정이기에 ERD 설계부터 진행합니다. 3. API 리스트업 및 문서 작성 개발해야할 API를 리스트업 하고 문서를 작성합니다. 문서에는 url, method, dto, exception, success example value 등이 담겨져 있어야하며, 문서가 먼저 나와야 클라이언트에서 목업 등을 만들어 작업하기 용이 합니다. 4. 테스트 코드 및 API Tdd로 하실 거면 테스트 코드를 먼저 해야합니다만 선택적임 부분이라 API와 같은 순서에 두었습니다.

DTO와 Entity 또는 Domain은 구분하셔야 합니다. 엔드포인트에서 딱 필요한 정보만 리턴해야합니다. ERD는 개발도중 수십차례 바뀌실꺼예요. 그에따른 Entity또한 변화를.가질텐데 DTO는 딱 정말 필요한것만 보내기때문에 수정할게 좀 줄어드실거예요