Pull Request

안녕하세요, 제이!! :smile:

이번 미션은 Web View와 DB를 연동하는 미션이라 쉽지 않았습니다.

4단계, 5단계의 필수 요구사항들 외에도, 아래의 선택 요구사항들 까지 모두 구현해 봤습니다.

- 체스 게임방을 만들고 체스 게임방에 입장할 수 있는 기능을 추가한다.
- 사용자별로 체스 게임 기록을 관리할 수 있다.

사전에 MySQL에서 java-chess/chess_game.sql 파일의 명령문들을 맨 위에서부터 맨 아래까지 순차적으로 실행해야 합니다. 이 과정을 먼저 마쳐야 제출한 애플리케이션을 실행하거나 테스트할 수 있습니다.

그때 제이와 얘기했던 "Piece와 Board간의 순환적 의존관계" 를 분리해 봤어요.

특정 Peice가 요청받은 이동 경로로 이동할 수 있는지 판단하는 객체를 따로 만들어, 책임을 분리했습니다.

이를 비롯해 제가 이번 미션에서 고민하고, 학습하고, 적용한 내용들을 아래 학습로그에 정리했어요!

그리고 맨 마지막에 질문도 있습니다!!

답변 해 주시면 정말 감사하겠습니다. :pray:

감사합니다!! :bow: :smile:

인비의 학습로그

[OOP] DTO - 5

내용

• Domain, Controller, View 간의 데이터 전달에 DTO를 사용했다.
• 필요한 데이터들을 알맞은 형태로 담아 전달했다.
• DTO를 통해 Layer들 간의 결합도를 낮췄다.

링크

• CommandRequestDTO
• 다른 DTO들

[OOP] Caching - 5

내용

• DB에 체스 보드 모든 칸들의 위치와 모든 색깔별 기물들을 저장해 두었다.
• 애플리케이션이 실행될 때 이 위치값들과 색깔별 기물들을 DB로부터 불러와, 객체 형태로 애플리케이션 내에 캐싱했다.
• 자주 쓰이는 값들을 캐싱해 DB 쿼리 조회 수를 매우 많이 줄여, 성능이 개선됐다.
• 애플리케이션 내에서 해당 객체들을 사용하기 편했다.

링크

• PositionsCache
• PiecesCache

[OOP] 점진적 리팩토링 - 5

내용

• Web View UI 와 DB를 적용하기 위해 많은 변경이 필요했다.
• 안전하게 점진적 리팩토링을 했다.
• 항상 모든 테스트코드들이 통과하도록 했다.
• 리팩토링에 확신을 갖고 자유롭게 할 수 있었다.
• 자주 테스트 하고 싶어졌다.

[DB] Query 최적화 - 5

내용

• DB에서 필요한 데이터들만 조회하는 쿼리를 작성했다.
• 원하는 데이터를 조회하기 위해 쿼리를 여러 번 날리지 않고, 한 방 쿼리로 가져왔다.
• 요청 쿼리 수가 확연히 줄어 성능이 개선됐다.

링크

• PlayerPiecePositionDAO

[MVC] 의존성 분리 - 5

내용

• Controller, Service는 Console용과 Web용이 따로 존재한다.
• 각 Controller, Service들은 하나의 ChessGame 도메인을 사용한다.
• 이는 도메인과 모든 Controller, Service들 간의 의존성이 낮다는 것을 의미한다.
• 다른 종류의 Controller, Service들을 부품 갈아 끼우듯이 자유롭게 교체할 수 있었다.

[OOP] Domain 의존성 분리 - 5

내용

• 이전에는 Board가 Piece를 알고, Piece가 Board를 알고 있었다.
• 이는 서로 의존성이 높음을 의미한다.
• 기물 이동 요청에 대해 이동이 가능한지 판단하는 책임을 MoveChecker 객체로 완전히 분리했다.
• Board와 Piece간의 의존성을 현저히 낮출 수 있었다.
• 이전에는 플레이어의 점수 계산을 Pieces 도메인에서 했다.
• 점수 계산 책임을 ScoreCalculator 객체로 분리했다.

링크

• MoveChecker
• ScoreCalculator

[DB] 테이블 연관관계 매핑 - 5

내용

• 인프런에서 김영한 님의 JPA 강좌에서 공부했던 내용들을 기반으로 DB 테이블 연관관계를 매핑했다.
• N : 1 (다대일) 관계를 실무에서 제일 많이 쓰고, N : M (다대다) 관계는 중간에 N : 1 (다대일), 1 : M (다대일) 관계의 중간 테이블을 만들어 풀어내야 한다고 하셨다. 그래야 매핑 관리에 유리하고, 각 매핑에 대한 추가적인 정보를 중간 매핑 테이블에 저장할 수 있기 때문이다.
• 김영한 님의 강의 내용을 바탕으로 위와 같이 테이블들을 매핑했다.

질문

1. Entity, Domain, Domain Model에 대해 궁금합니다.

   1. Entity는 DB의 테이블과 직접적으로 맞닿아 있는 객체라고 알고 있습니다. 굳이 이해가 쉽도록 표현하자면, "DB와 Domain 사이의 DTO같은 느낌??". 그렇다면, Entity는 Domain 인가요? 아닌가요? 상황에 따라 다를까요? 보는 관점에 따라 다를까요? 헷갈리네요 :sob:. 사실 JPA를 보면, 모든 Entity 클래스를 Domain으로 보는 것 같기도 해요. 결국 개발 대상의 클래스니까요. 구분 기준을 어떻게 두어야 할까요?

   2. Domain Model은 뭘까요? ERD처럼 Domain들에 대한 설계? "Domain들에 대한 클래스 다이어그램" 인가요?? 구글링을 해봐도 잘 모르겠습니다. :cry: