[🚀 사이클2 - 미션 (기물 확장 + DB 적용)] 달수 미션 제출합니다.

[soohyun1904]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

---

어떤 부분에 집중하여 리뷰해야 할까요?

1. 전체적인 테스트 구조와 설계에 대한 객관적인 평가를 듣고 싶습니다.
2. 현재 리포지토리, 서비스, DAO에 대한 테스트가 부재한 상황인데, 이에 대한 보완 방향이 궁금합니다.
3. 도메인 모델에서 객체의 책임을 더 개선하거나 수정할 지점이 있는지 알고 싶습니다.
4. 현재 적용한 DB 사용 방식이 프로젝트 규모와 요구사항에 적절한지 검토 부탁드립니다.

장기 프로젝트 영속성 계층 및 도메인 설계 리뷰 요청

---

1. 객체 설계 및 도메인 모델링 (Domain & Object Design)

Q. Score를 필드(State)로 유지할지 메서드(Behavior)로 계산할지 여부

• 질문: 현재 기물 객체 내부에 점수를 인스턴스 변수로 가지도록 구현했습니다. 하지만 점수는 게임 종료 시점이나 점수 확인 시점에만 사용되는데, 이를 상시 변수로 들고 있는 것이 맞을까요?
• 세부 내용: 인스턴스 변수를 줄여 객체를 가볍게 유지하고 싶었습니다. 점수 출력 시점에만 호출되어 상수값을 반환하는 메서드 방식이 객체의 자율성과 메모리 측면에서 더 나은 설계가 될 수 있을지 리뷰 부탁드립니다.

Q. 기물 이동 객체의 지식 범위 (궁성 위치 인지)

• 질문: 기물의 이동 로직을 담당하는 객체가 '궁성(Palace)'의 위치 정보를 직접 알고 있어도 될까요?
• 세부 내용: Position 자체가 '궁성 여부'를 속성으로 가지는 것과, 이동 로직 객체가 궁성 좌표 범위를 상수로 들고 관리하는 것 중 어느 쪽이 결합도를 낮추고 응집도를 높이는 데 유리할까요?

---

2. 패턴 적용 및 설계 원칙 (Design Patterns)

Q. 데코레이터 패턴 도입 보류와 클래스 폭발 문제

• 질문: 기물 이동 규칙 확장을 위해 데코레이터 패턴을 검토했으나, 모든 패턴마다 새로운 객체를 추가해야 하는 '클래스 폭발' 우려로 보류했습니다.
• 세부 내용: 데코레이터 패턴이 전략 패턴(Strategy)이나 상속보다 실질적인 이득을 주는 시점이 구체적으로 언제일지 궁금합니다.

---

3. 영속성 계층 및 저장 전략 (Persistence & Infrastructure)

Q. 전체 삭제 후 삽입 업데이트 전략

• 질문: 기물 이동 시 개별 id를 추적해 UPDATE 하지 않고, 해당 게임의 기물을 모두 지운 뒤(DELETE) 현재 도메인 상태를 다시 넣는(INSERT) 방식을 택했습니다.
• 세부 내용: 도메인 모델이 DB 식별자(id)를 몰라도 되게끔 하여 '도메인 순수성'을 지켰습니다. 다만, 이러한 방식이 실무 환경의 성능이나 데이터 무결성 측면에서 어느 정도까지 허용될 수 있는 설계인지 궁금합니다.

Q. 저장 시점: 매 수마다 저장 vs 일괄 저장

• 질문: 현재는 매 회차(play)마다 DB에 동기화하고 있습니다.
• 세부 내용: 장애 복구에는 유리하지만 DB I/O가 빈번합니다. 서비스 규모와 장기 게임의 특성을 고려했을 때 이 방식이 합리적인지, 아니면 메모리 캐싱 후 특정 시점에 저장하는 방식이 권장되는지 의견 부탁드립니다.

---

4. 서비스 레이어 및 데이터 전달 (Architecture & Flow)

Q. 조인(Join) 대신 다중 쿼리 실행의 적절성

• 질문: 게임 메타 정보와 기물 리스트를 가져올 때 JOIN을 쓰지 않고 각각의 DAO를 호출했습니다.
• 세부 내용: DAO 간의 책임을 명확히 분리하고 쿼리를 단순하게 유지하기 위함입니다. 성능상 큰 문제가 되지 않는다면 이 구조를 유지해도 괜찮을까요?

Q. 서비스와 도메인 간의 정보 전달 범위 및 Mapper의 위치

• 질문: 서비스가 DAO로부터 받은 정보를 도메인에게 어느 정도까지 전달해야 할까요? 또한 리포지토리가 매퍼를 소유하고 변환하는 구조가 적절할까요?
• 세부 내용: 현재 리포지토리에서 매퍼를 통해 엔티티들을 합치고 도메인 객체로 변환하여 서비스에 넘겨줍니다. 도메인이 id를 전혀 모르는 현재의 구조가 장기적으로 확장성에 도움이 될지 리뷰 부탁드립니다.

---

5. 테스트 및 예외 처리 (Testing & Exception)

Q. TDD 진행 순서와 전략

• 질문: DB와 연동되는 기능을 개발할 때, 데이터 결과물을 검증하는 DB 테스트를 먼저 짜야 하는지, 아니면 서비스 로직을 먼저 짜야 하는지 기준이 궁금합니다.
• 세부 내용: 서비스 레이어의 테스트는 실제 DB를 연동하여 통합 테스트로 진행해야 하는지, 혹은 모킹을 통해 도메인 로직만 검증하는 것이 맞는지 궁금합니다.

Q. JDBC 예외 처리 및 설정 파일 위치

• 질문: DAO에서 발생하는 SQLException을 서비스 계층에서 커스텀 예외로 변환하고 있습니다. 이 기술적 예외를 어디까지 숨겨야 하며, 사용자에게 메시지를 전달하는 가장 적절한 방식은 무엇일까요?

Q. DB 설정 클래스 위치

질문 : 추가로 DB 연결을 설정하는 Config 클래스는 프로젝트 구조상 어느 위치(패키지)에 두는 것이 가장 관리하기 편할까요?

[Arachneee]

안녕하세요 달수님!

리뷰어 백호입니다. 😄

사이클 2도 잘 해주셨네요. 깔끔하게 잘 하신 것 같아요. 고생하셨습니다.

코멘트 남겼으니 확인해주세요~

1. 객체 설계 및 도메인 모델링 (Domain & Object Design)
   Q. Score를 필드(State)로 유지할지 메서드(Behavior)로 계산할지 여부
   질문: 현재 기물 객체 내부에 점수를 인스턴스 변수로 가지도록 구현했습니다. 하지만 점수는 게임 종료 시점이나 점수 확인 시점에만 사용되는데, 이를 상시 변수로 들고 있는 것이 맞을까요?
   세부 내용: 인스턴스 변수를 줄여 객체를 가볍게 유지하고 싶었습니다. 점수 출력 시점에만 호출되어 상수값을 반환하는 메서드 방식이 객체의 자율성과 메모리 측면에서 더 나은 설계가 될 수 있을지 리뷰 부탁드립니다.

score를 인스턴스 변수로 가지지 않으면 Piece의 score 메소드를 추상 메소드로 만들고 모든 Piece 구현체에서 해당 메소드를 구현하게 해야할 것 같네요. 이거는 Piece의 점수가 구현체마다 고정인지 아닌지에 따라서 선택하는 것이 좋을 것 같습니다. 메모리 측면에서는 별 차이가 없을 것 같아요.

Q. 기물 이동 객체의 지식 범위 (궁성 위치 인지)
질문: 기물의 이동 로직을 담당하는 객체가 '궁성(Palace)'의 위치 정보를 직접 알고 있어도 될까요?
세부 내용: Position 자체가 '궁성 여부'를 속성으로 가지는 것과, 이동 로직 객체가 궁성 좌표 범위를 상수로 들고 관리하는 것 중 어느 쪽이 결합도를 낮추고 응집도를 높이는 데 유리할까요?

궁성 내부에서의 움직임이니까 지금처럼 궁성 내부 움직이는 전략을 추상화하는 것 좋은 것 같아요! 👍 Palace -> Position에 대한 의존은 불가피한 것 같아요. 그런데 Position에 '궁성 여부' 속성이 들어가는 것은 Position -> Palace에 대한 간접 의존이 생기는 것이라고 생각해요. 그래서 지금 구조가 좋은 것 같습니다!

2. 패턴 적용 및 설계 원칙 (Design Patterns)
   Q. 데코레이터 패턴 도입 보류와 클래스 폭발 문제
   질문: 기물 이동 규칙 확장을 위해 데코레이터 패턴을 검토했으나, 모든 패턴마다 새로운 객체를 추가해야 하는 '클래스 폭발' 우려로 보류했습니다.
   세부 내용: 데코레이터 패턴이 전략 패턴(Strategy)이나 상속보다 실질적인 이득을 주는 시점이 구체적으로 언제일지 궁금합니다.

전략 패턴이나 상속은 하나의 전략이 런타임에 고정되지만 데코레이터 패턴을 사용하면 런타임에 여러 겹을 동적으로 쌓을 수 있는 장점이 있다고 생각해요. 또한 핵심 로직이나 부가 로직들을 분리하고 싶을 때 사용할 수 있죠. 지금 수준에서는 사용하지 않는 것이 적절한 선택이었던 것 같아요.

3. 영속성 계층 및 저장 전략 (Persistence & Infrastructure)
   Q. 전체 삭제 후 삽입 업데이트 전략
   질문: 기물 이동 시 개별 id를 추적해 UPDATE 하지 않고, 해당 게임의 기물을 모두 지운 뒤(DELETE) 현재 도메인 상태를 다시 넣는(INSERT) 방식을 택했습니다.
   세부 내용: 도메인 모델이 DB 식별자(id)를 몰라도 되게끔 하여 '도메인 순수성'을 지켰습니다. 다만, 이러한 방식이 실무 환경의 성능이나 데이터 무결성 측면에서 어느 정도까지 허용될 수 있는 설계인지 궁금합니다.

도메인이 DB 식별자를 알지 못하게 하기 위해서 DELETE, INSERT 전략을 선택하신걸까요? 도메인이 id를 가지면 도메인 순수성이 깨지는 걸까요?

Q. 저장 시점: 매 수마다 저장 vs 일괄 저장
질문: 현재는 매 회차(play)마다 DB에 동기화하고 있습니다.
세부 내용: 장애 복구에는 유리하지만 DB I/O가 빈번합니다. 서비스 규모와 장기 게임의 특성을 고려했을 때 이 방식이 합리적인지, 아니면 메모리 캐싱 후 특정 시점에 저장하는 방식이 권장되는지 의견 부탁드립니다.

매 회차가 몇초 단위로 진행 될텐데 DB I/O 에대한 성능은 신경쓰지 않아도 되지 않을까요?

4. 서비스 레이어 및 데이터 전달 (Architecture & Flow)
   Q. 조인(Join) 대신 다중 쿼리 실행의 적절성
   질문: 게임 메타 정보와 기물 리스트를 가져올 때 JOIN을 쓰지 않고 각각의 DAO를 호출했습니다.
   세부 내용: DAO 간의 책임을 명확히 분리하고 쿼리를 단순하게 유지하기 위함입니다. 성능상 큰 문제가 되지 않는다면 이 구조를 유지해도 괜찮을까요?

성능 상 문제가 되지 않는다면 괜찮다고 생각해요.

Q. 서비스와 도메인 간의 정보 전달 범위 및 Mapper의 위치
질문: 서비스가 DAO로부터 받은 정보를 도메인에게 어느 정도까지 전달해야 할까요? 또한 리포지토리가 매퍼를 소유하고 변환하는 구조가 적절할까요?
세부 내용: 현재 리포지토리에서 매퍼를 통해 엔티티들을 합치고 도메인 객체로 변환하여 서비스에 넘겨줍니다. 도메인이 id를 전혀 모르는 현재의 구조가 장기적으로 확장성에 도움이 될지 리뷰 부탁드립니다.

DAO, 도메인, 엔티티, 레포지토리 전부 어떻게 다른 역할을 가지고 있고 왜 존재하나요? 도메인이 id를 몰라야하는 이유는 뭘까요?

5. 테스트 및 예외 처리 (Testing & Exception)
   Q. TDD 진행 순서와 전략
   질문: DB와 연동되는 기능을 개발할 때, 데이터 결과물을 검증하는 DB 테스트를 먼저 짜야 하는지, 아니면 서비스 로직을 먼저 짜야 하는지 기준이 궁금합니다.
   세부 내용: 서비스 레이어의 테스트는 실제 DB를 연동하여 통합 테스트로 진행해야 하는지, 혹은 모킹을 통해 도메인 로직만 검증하는 것이 맞는지 궁금합니다.

무엇을 테스트하고 싶은지에 따라 다를 것 같아요. 도메인 로직을 검증하고 싶으면 모킹을 하면 되고 DB 연동까지 테스트하고 싶으면 통합 테스트를 하면 됩니다. 저라면 DB 관련 로직이 복잡하니까 DB 테스트 먼저 진행했을 것 같아요. 아니면 서비스 레이어는 단순하니까 DB를 모킹하는 것은 의미가 없다고 생각하고 통합테스트를 했을 것 같습니다.

Q. JDBC 예외 처리 및 설정 파일 위치
질문: DAO에서 발생하는 SQLException을 서비스 계층에서 커스텀 예외로 변환하고 있습니다. 이 기술적 예외를 어디까지 숨겨야 하며, 사용자에게 메시지를 전달하는 가장 적절한 방식은 무엇일까요?

예외를 catch할 수 도 있고 그대로 전파 할 수 도 있는데 언제 catch하고 언제 전파하는 것이 좋을지 생각해보면 좋을 것 같아요.

Q. DB 설정 클래스 위치
질문 : 추가로 DB 연결을 설정하는 Config 클래스는 프로젝트 구조상 어느 위치(패키지)에 두는 것이 가장 관리하기 편할까요?

설정 파일이니까 config 패키지가 어울리는 것 같아요.

[soohyun1904]

Q. DELETE + INSERT 전략

• 당시 도메인 객체에 id라는 개념 자체를 넣지 않았기 때문에, 개별 기물을 추적할 수 없어서 DELETE + INSERT 전략을 선택했습니다. 지금 돌이켜보면, 도메인 객체도 Entity로서 식별자를 가져야 한다고 생각합니다. Piece에 id가 있었다면 변경된 기물만 UPDATE하는 방식이 가능했을 것이고, 도메인 순수성과 id를 갖는 것은 충돌하지 않는다고 생각합니다.

Q. 매 수마다 저장 vs 일괄 저장

• 무의식적으로 'DB I/O는 비싸니까 줄여야 한다'는 생각에 매몰되어 있었는데, 도메인의 특성(사람 간의 플레이)을 생각해보면 매 수가 수 초~수 분 간격으로 일어나기 때문에 현재 규모에서는 전혀 성능에 무리가 가지 않는다는 것을 깨달았습니다.
  오히려 일괄 저장 방식을 도입했을 때 서버 장애 시 복구가 불가능하다는 치명적인 단점과, 캐시-DB 간 정합성을 맞추기 위한 로직의 복잡도를 고려하면 배보다 배꼽이 커지는 오버 엔지니어링이 될 것 같습니다.
  현재의 트래픽과 도메인 특성상 데이터의 안정성(장애 복구)을 챙기는 현재 방식(매 수마다 저장)을 유지하는 것이 훨씬 합리적이라고 생각합니다. 좋은 시각을 열어주셔서 감사합니다!

Q. JDBC 예외 처리

• 기술적 예외는 발생한 레이어에서 의미 있는 예외로 변환해서 전파해야 한다고 생각합니다. 기준은 "해당 레이어에서 복구하고 정상 흐름으로 돌아갈 수 있는가"입니다. 복구 가능하면 catch하고, 불가능하면 전파합니다. 예를 들어 DAO에서 중복 키가 발생하면 DuplicateGameException으로 변환하고, Controller에서 이를 catch해서 사용자에게 안내 후 재입력을 받을 수 있습니다. 반면 커넥션 실패 같은 기술적 예외는 어떤 레이어에서도 복구할 수 없으므로 RuntimeException으로 감싸서 전파하고, Controller에서 최종적으로 catch해서 사용자에게는 "시스템 오류가 발생했습니다" 정도의 메시지만 전달하는 것이 적절하다고 생각합니다.

Q. 각자 의 역할

• 각자의 역할: 도메인(핵심 로직), 엔티티(DB용 그릇), DAO(DB 접근), 레포지토리(도메인-DB 간 번역기)로 역할을 나누어, 순수한 비즈니스 로직이 DB 기술에 오염되는 것을 막기 위해 존재합니다.
• 도메인이 ID를 몰라야 하는 이유: DB 테이블의 PK(Auto Increment 등) 같은 특정 인프라 기술에 도메인이 종속되는 것을 막기 위해서입니다.
• 나의 생각: 하지만 상태가 같아도 객체를 논리적으로 구별해야 한다면, 도메인도 '자체 고유 식별자'를 가질 수 있다고 봅니다. 이 도메인용 ID를 DB 기술용 ID와 철저히 분리해서 다루면 충분하다고 생각합니다.

[soohyun1904]

이번에 커넥션 풀, 트랜잭션 관리, Fake 테스트 구조를 잡으면서 막히는 부분이 많아 AI의 도움을 적극적으로 받았습니다! 아직 100% 제 지식으로 체화하진 못해서 아쉬움은 남지만, 힌트를 얻어 뼈대를 잡을 수 있었습니다. 피드백 주신 부분들 바탕으로 계속 다듬어가 보겠습니다!

[Arachneee]

안녕하세요 달수sla!

코멘트 잘 반영해주셔서 감사합니다. 😄

코멘트 조금 남겨놨는데 요구 사항 모두 충족해서 머지해도 될 것 같아요. 혹시 조금 더 수정하고 싶은 부분이 있을까봐 한번 더 리뷰 요청주시면 머지하겠습니다.

[soohyun1904]

더 개선하고 싶은 부분이 있지만, 여기서 마무리하고 다른 공부를 이어가겠습니다. 혹시 이번 코드에서 추가로 아쉬웠던 부분이 있으시면 말씀해주시면 다음에 참고하겠습니다. 이번 리뷰를 통해 많이 배웠습니다. 좋은 리뷰 감사했습니다.