[팀 1차 보고서] 초기 아키텍처 및 개발 컨벤션 회의록

[mainlib990]

팀 회의록

• 회의 일자: 2025년 10월 20일
• 주요 안건: 프로젝트 초기 아키텍처 및 개발 컨벤션 논의

---

1. 주요 논의 내용

■ Persistence Model과 Domain Model 분리 여부

• 결론: 해당 안건은 내일 추가 논의 후 최종 결정하기로 함.
• 주요 의견:
  • 김재원님: DB/프레임워크에 대한 종속성, 영속성 컨텍스트와의 결합도를 낮추기 위해 JPA 엔티티와 별개의 POJO 클래스로 Domain Model을 정의하자는 의견.
    • 구현 방안: JPA 엔티티에는 연관관계 대신 외래 키(FK)를 사용하고, 조회가 필요한 경우 별도의 DTO로 프로젝션.
    • 장점: 복잡도 감소, OSIV false 설정 시 구현 용이, N+1 문제 방지.
    • 단점: 객체 그래프 탐색 불가, 조회용 DTO 추가 개발 공수.
  • 이치호님: DB와 객체의 종속은 완전히 분리하기 어려우므로, 개념적 분리는 하되 최대한 유사한 구조로 설계하는 것이 효율적이라는 의견.
  • 김승빈님 정리: 두 모델을 분리할 경우, 객체 연관관계 대신 외래 키를 직접 사용하게 되어 프로젝션 조회 등에 유리한 이점이 있음.

---

2. 결정 사항

■ 개발 컨벤션

1. 커밋 컨벤션
   • 타입은 fix, feat, chore, docs, refactor, test 만 사용.
   • 커밋 메시지는 API 명세서의 설명과 동일하게 작성.
2. 코드 스타일
   • IntelliJ IDEA의 기본 코드 스타일 컨벤션을 따름.
3. 개발 원칙
   • 엔지니어링 3원칙(KISS, YAGNI, DRY)을 항상 염두에 두고 개발.

■ 아키텍처

1. 패키지 구조
   • Package by Feature 방식으로 구성.
2. Service Layer 설계
   • (입력/출력) Service는 Controller에 DTO를 반환하며, Mapper의 위치도 Service Layer로 결정.
     • (참고: GitHub Discussion [투표] Service Layer의 반환 타입 및 Mapper 위치에 대한 아키텍처 논의 #4 (https://github.com/orgs/codeit-spring-6-part2-team2/discussions/4))
   • (인터페이스) Service는 반드시 인터페이스와 구현체로 분리하여 작성.
     • (참고: GitHub Discussion [투표] Service Layer 인터페이스 도입에 대한 아키텍처 논의 #5 (https://github.com/orgs/codeit-spring-6-part2-team2/discussions/5))
   • (네이밍) Service 구현체의 이름은 Basic을 접두어로 사용 (예: BasicMemberService).
3. 데이터 조회 방식
   • JPQL, Projection, QueryDSL 등은 특정 기술을 강제하지 않고, 상황에 맞게 선택적으로 적용.

■ 프로젝트 관리

1. 일정 관리
   • 이번 프로젝트에서는 별도의 일정 관리 툴을 사용하지 않음.
2. 문서화
   • 모든 관련 문서는 한글로 작성하는 것을 원칙으로 함.

---

3. 공유 자료

• 이치호님: 팀 그라운드 룰 설정에 참고할 만한 실제 예시 자료 공유.
  • (링크: 팀 프로젝트 그라운드 룰 실제 예시 (https://claremont.tistory.com/entry/팀-프로젝트-그라운드-룰-실제-예시))

---

4. To-Do / 다음 회의 안건

• Persistence Model과 Domain Model 분리 여부에 대해 최종 결정.