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

[koomingu]

안녕하세요 두둠, 밍구입니다.

PR이 늦어져 죄송합니다.

마감 이후 요청한 PR에 대한 피드백은 리뷰어의 선택사항임을 인지하고 있습니다.

이번 장기 미션에서는 depth1을 지키고 가독성을 높이는 데에 집중하였고, 기능 구현이라도 해서 제출해야겠다는 마음에 테스트 코드를 작성하지 못했습니다.

체크 리스트

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

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

기존 코드에서 변경 및 추가된 부분

---

• 궁성 영역: 기물마다 궁성 내 행마법이 다르기 때문에, 각 기물의 이동 전략 내부에서 궁성 안에 있는지와 궁성 내 대각선 이동 가능 여부를 판단하도록 하여서 응집도를 높였습니다.
• 점수 계산: 각 기물 객체가 자신의 점수를 필드로 가지며 후공인 한나라에게는 1.5점의 보정치를 부여하도록 했습니다. 매 턴마다 총 점수를 계산합니다.
• 게임 종료: 실시간으로 보드 내의 왕의 개수를 카운트합니다. 어느 한 쪽의 왕이 잡혀 개수가 2개 미만이 되는 즉시 isKingCaptured()가 true를 반환하며 게임이 종료되게 하였습니다.

Service 계층 도입 및 역할 분리

• Domain: 장기 규칙만 알도록 하였습니다.

• Controller: 사용자의 입출력을 관리하며, 서비스에 요청을 전달하고 전체적인 게임의 실행 흐름을 제어합니다.

• DAO: SQL 쿼리를 실행하며 및 데이터 영속화를 담당합니다.

• Service: 도메인 객체의결과를 DAO를 통해 DB에 반영합니다.

• JanggiService 시퀀스 다이어그램

  1. User: 기물 이동 입력 (play 1, 2)
  2. Controller: janggiService.movePiece() 호출
  3. Service: board.move() 호출 (도메인 로직으로 검증 및 이동)
  4. Board: 이동 성공 여부 반환
  5. Service: pieceDao.updatePosition() 호출 (DB 기물 위치 변경)
  6. Service: gameDao.updateMetadata() 호출 (현재 턴, 점수 DB 반영)
  7. Controller: 성공 메시지 및 보드 출력

DB

---

• DB는 MySQL 8.0을 사용하며, Docker 컨테이너로 띄웠습니다.
• 기존 MySQL 기본 포트(3306)와의 충돌을 피하기 위해 3308 포트를 외부 포트로 매핑했습니다.
• 테이블 구조:
  • game_room: 게임의 현재 턴, 진행 상태, 점수, 생성일을 저장합니다.
  • piece_position: 보드 위의 모든 기물 좌표(row, col)와 종류, 팀 정보를 저장합니다. game_id를 외래키로 가지며 방 삭제 시 기물 정보도 삭제되도록 하였습니다.

기물 저장 방식

• 보드 전체를 매번 저장하지 않고 기물 각각의 좌표를 매번 저장하는 방식으로 구현했습니다.
• 이동(UPDATE): 이동하는 기물의 row, col 정보만 수정합니다.
• 포획(DELETE): 행마의 목적지에 상대 기물이 존재할 경우, 이동 쿼리 실행 전 해당 좌표의 데이터를 삭제한 뒤, 이동하는 기물의 좌표를 목적지 좌표로 수정합니다.
• 특정 게임방이 삭제될 때 연관된 모든 기물 데이터가 같이 제거됩니다.

트랜잭션

별도로 트랜잭션을 설정하지 않았기 때문에, DAO의 각 메서드(update, delete 등)가 실행될 때마다 DB와 Connection을 맺고, 쿼리가 성공하면 DB에 반영하는 Auto-commit 방식으로 동작하도록 하였습니다.

JanggiService.movePiece() 메서드 안에서 '기물 삭제 - 위치 수정 - 메타데이터 업데이트’라는 3번의 쿼리가 발생하기 때문에 플레이 도중 게임이 꺼진다면 데이터 불일치 상태가 될 수 있습니다. 우선 기능 구현을 우선적으로 하는 것을 목표로 잡았기 때문에 향후 트랜잭션을 도입할 생각입니다.

실행 가이드

---

1. Docker 환경 띄우기

   1. Docker를 켭니다.

   2. 터미널에서 프로젝트 루트 경로(java-janggi)로 이동합니다.

   3. 아래 명령어를 입력하여 DB를 백그라운드에서 실행합니다.

      docker-compose up -d

2. DB 연결 확인

   1. IntelliJ 우측 Database 창에서 janggi 커넥션을 새로고침하여 데이터가 잘 보이는지 확인합니다.
   2. 포트가 3308로 설정되어 있는지 체크합니다.

3. Java 프로그램 실행

   1. Application.java를 실행합니다.

질문

---

Q. 현재는 엔티티와 DTO의 역할을 한 클래스에서 담당하고 있는데, 어느 수준까지 분리하는 것이 좋을까요?

현재 GameDao는 영속성 계층의 접근을 담당하는 DAO로 구현했고, GameRoomDto는 DB 테이블의 데이터를 매핑하면서 동시에 계층 간 데이터를 전달하는 역할을 수행하고 있습니다.

1. 현재 GameRoomDto가 사실상 엔티티와 DTO의 역할을 수행하는 것으로 볼 수 있다고 생각하는데, 이를 분리하여 GameRoomEntity를 따로 두는 것이 나을지 궁금합니다.
2. 만약 분리한다면, DB에서 가져온 엔티티를 도메인 객체로 변환하고, 다시 DTO로 변환하는 과정에서 발생하는 코드 복잡도를 어떻게 관리하는 것이 좋을까요?
3. 실무에서 도메인과 DB 스키마가 거의 일치하는 상황에서도 이 계층들을 항상 분리하시는지, 아니면 분리를 언제 고려하시는지 궁금합니다.

Q. 적절한 추상화 수준이 궁금합니다.

현재 Application에서 생성자 주입을 통해 Controller → JanggiService → GameDao/PieceDao 순으로 의존성을 주입하고 있습니다. 하지만 서비스 계층이 인터페이스가 아닌 DAO에 직접적으로 의존하고 있어, 강한 결합이 있는 것 같습니다.

1. 현재 단계에서 GameRepository와 같은 인터페이스를 도입하여 추상화 계층을 한 번 더 두는 것이 나을까요?
2. 현재처럼 Application에서 모든 객체를 조립하여 주입하는 방식이 장기 미션에서 적절한지 궁금합니다.