1. Validation 로직 위치 (중앙집중식 vs. 도메인별 분리)

• 논의: Validation 로직(특히 권한 검증 외 데이터 유효성 검사)을 common 패키지에 둘지, 각 도메인별로 분리할지 질문.
• 멘토님 의견: (데이터 유효성 검사 측면에서) 도메인별로 나누는 것이 편하다.
  • 이유: 테스트 용이성, 코드 응집도를 고려했을 때 같은 도메인 관련 검증 로직은 해당 도메인 내에 두는 것이 좋다.
  • 애매한 경우: 공통인지 도메인 특정인지 애매한 로직이 발생하면, 그때 가서 다시 논의하여 결정하자.

2. 도메인 패키지 구조 및 접근 제어

• 논의: 도메인 패키지 내부를 기능별 하위 패키지로 더 세분화하는 것에 대한 질문. (예: com.soda.member 내부에 service, repository, dto 등)
• 멘토님 의견: 과도한 하위 패키지 분리는 선호하지 않는다.
  • 이유: 같은 패키지 내에서는 default(package-private) 접근 제한자를 활용하여 외부에서의 직접적인 접근을 제한하고 도메인 모델을 보호하는 것이 좋다. (현재는 대부분 public이라 외부에서 자유롭게 접근 가능)
  • 원칙: 도메인 로직은 해당 도메인의 Service를 통해서만 접근하도록 강제하는 것이 좋다. 패키지를 너무 잘게 나누면 default 접근 제한자 활용이 어려워진다.
  • 구조 제안: 현재 '도메인+피처'로 혼합된 구조보다는, '도메인' 중심으로 패키지를 구성하고 관련 클래스들을 모아두는 것을 고려해보자.
  • 참고 자료: SLASH 22 영상 추천 (링크). Import 문을 통해 코드 간의 결합도(Coupling)를 파악할 수 있다는 내용 참고.
• 추가 논의: Article 패키지 안에 Article, Comment 하위 패키지를 두는 구체적인 구조는 추후 다시 논의하기로 함.

3. API 설계 (게시글 작성 + 파일/링크 첨부)

• 논의: 게시글 작성 시 파일/링크 정보를 포함하여 하나의 API로 처리 vs 게시글 생성 후 별도 API로 파일/링크 추가 처리 방식 비교.
• 멘토님 의견: (파일 업로드 제외하고) 하나의 API로 처리하는 것을 선호한다.
  • 이유: RESTful 관점에서는 여러 API가 맞을 수 있지만, 프론트엔드 개발 편의성 측면에서 하나의 API가 더 좋다. 서버 내부에서 로직을 분리하여 처리하면 된다.
  • 변경 용이성: 두 방식 간 변경 용이성의 큰 차이는 없어 보인다.
  • 성능: 파일 업로드를 제외하면 성능 이슈는 크지 않다. 우선 편의성을 고려하자.
• 파일 업로드:
  • 권장 방식: 프론트엔드에서 직접 S3 같은 저장소로 파일을 업로드하고, 백엔드에는 업로드된 파일의 주소(URL)만 전달하는 방식이 좋다. (성능, 보안 - Presigned URL 활용)
• 결론: **파일 업로드는 별도 처리(프론트엔드 직접 업로드)**하고, 게시글 내용과 링크 정보 등 나머지는 하나의 API로 묶어서 처리하는 것을 권장.

4. 로그 관리 (특히 History 로그)

• 논의: 데이터 변경 이력(생성/수정/삭제) 로그 관리 방식 질문 (도메인별 History 테이블 vs 단일 테이블).
• 멘토님 의견:
  • RDB는 로그 저장에 이상적이지 않다. (특히 스키마가 다른 경우)
  • NoSQL (MongoDB 등) 사용 고려: 다양한 형태의 로그(스키마가 다른 History) 저장에 유리하다. 하지만 당장 도입은 어려울 수 있다.
  • 현실적인 접근:
    1. RDB의 JSON 타입 필드 활용: History 클래스/테이블을 만들고, 변경 전/후 데이터 등을 JSON 형태로 저장한다. (도메인 타입, 변경 내용, 변경자, ID 등 포함)
    2. 이렇게 하면 추후 MongoDB 등으로 마이그레이션하기 용이한 구조가 된다.
    3. 일단 RDB + JSON 방식으로 구현하고, 프로젝트 완성 후 시간적 여유가 되면 MongoDB 도입을 고려해보자.
  • 로그 검색/분석: ELK 스택 (Elasticsearch, Logstash, Kibana) 언급. 특히 Elasticsearch는 로그 검색/조회에 강점이 있어 많이 사용된다.
• 애플리케이션 로그: History 로그와 별개로, 서버 상태 확인, 에러 추적 등을 위한 **애플리케이션 로그(Logback 등 활용)**는 당연히 남겨야 한다. 서버 환경에서의 관찰 가능성을 위해 중요하다.

5. 순환 참조 문제 해결 ('서비스당 레파지토리 하나' 규칙 하)

• 논의: '서비스당 레파지토리 하나' 규칙을 지키려다 발생하는 순환 참조 문제 해결 방안 질문 (1. 상위 서비스에서 처리, 2. 규칙 완화, 3. 퍼사드 패턴).
• 멘토님 의견:
  • 2번(규칙 완화)은 좋지 않은 해결책이다.
  • 1번(상위 서비스에서 하위 엔티티 생성/처리)과 3번(퍼사드 패턴) 모두 유효하고 좋은 접근 방식이다. 상황에 맞게 선택할 수 있다.
  • '서비스' 용어의 모호성: MVC의 서비스 레이어와 DDD의 도메인 서비스/애플리케이션 서비스 등 용어가 혼용되어 혼란을 줄 수 있다. 우리 프로젝트에서의 '서비스' 역할을 명확히 할 필요가 있다.
  • DDD/OOP 관점: 객체지향 원칙을 잘 지키고 도메인을 분석하다 보면 자연스럽게 이런 패턴(상위 서비스 처리, 퍼사드 등)들이 나타나게 된다. DDD는 도메인 분석 및 구현, 관계 정리에 도움을 준다.
• 결론: 1번 또는 3번 방식을 적용하고, 구체적인 코드는 추후 리뷰하기로 함. 2번 방식(단순히 여러 Repository 참조 허용)은 지양하자.