1. 도메인 중심 구조 논의:
•
도메인 중심으로 각 회원, 로그인, 게시판 단위로 컨트롤러, 서비스, 레포지토리 구성하는 방식
•
계층형 구조는 초기 프로젝트나 작은 규모에서 유리하지만, 유지보수나 확장성이 떨어질 수 있음
•
중대형 프로젝트에서는 도메인 중심의 구조가 더 일반적임 -> 도메인 중심 구조 채택
2. 브랜치 관리:
•
개인 브랜치를 생성하면 충돌 가능성이 높아질 수 있다는 의견
•
브랜치를 기능별로 나누고, 푸시와 머지는 모든 팀원의 승인을 받은 후 진행하기로 합의.
•
브랜치 명칭 제안: feature/sign-up, feature/login, feature/password, feature/member
3. DTO 및 엔티티 네이밍:
•
DTO와 컨트롤러에는 접미사를 붙이고, 엔티티는 접미사 없이 이름만 사용하기로 함
•
DTO는 MemberRequest, MemberResponse와 같이 별도 클래스로 구분
4. PR 및 이슈 관리:
•
PR은 작은 단위로 자주 하며, AS-IS와 TO-BE 형식으로 작성
•
이슈 템플릿도 설정하여 트러블슈팅 기록을 남길 예정
•
PR 시, 커밋 템플릿을 사용해 코드 변경 사항을 기록하고, 이슈 템플릿으로는 정상적으로 작동하지 않는 상황을 공유
5. 보안 및 설정 관리:
•
보안 설정 파일(yml 등)은 GitHub에 올리지 않고, 노션이나 구글 독스를 통해 공유하기로 함
•
개발 초기에는 JWT 기반 인증을 사용하고, 이후에 시큐리티를 적용하기로 합의
6. 회원 기능 개발 분담:
•
JWT 로그인 및 회원가입 구현
•
비밀번호 찾기 및 재설정 기능 개발
•
회원 정보 조회 및 수정 기능 구현
7. 백엔드 프로젝트 구조 논의:
•
기본 패키지 구조를 설정하면서 domain과 global로 나누기로 결정.
•
domain 패키지에는 기능별로 패키지를 만들고, 공용으로 사용하는 설정(config) 패키지는 global에 두기로 함
•
기본 패키지 구조를 설정하고 메인 패키지 이름을 com.onedrinktoday.backend로 수정
8. 클래스 및 패키지 구조 설정:
•
domain에 클래스와 레포지토리를 포함시켜 기능별로 관리할 예정
•
현재는 config를 포함한 기본적인 구조만 설정하고, 이후에 SwaggerConfig 등 필요한 설정 파일을 추가하기로 함
9. ERD 수정 사항:
•
삭제 여부를 boolean 값으로 관리하는 대신, deleted_at이라는 timestamp 필드를 추가하여 관리하기로 결정
•
이 방식은 deleted_at 필드가 null일 경우 삭제되지 않은 것으로, null이 아닌 경우 해당 시간에 삭제된 것으로 처리할 수 있어 더 유연함
•
이에 따라 ERD도 deleted(boolean)에서 deleted_at(timestamp)으로 수정하기로 함
10. 기타 논의 사항:
•
FE와 BE는 각각 배포하는 방식으로 진행