이번 페어는 토리~ 🐿️
1단계 미션에서 궁금했던 것
- foreign key를 삭제해서 테스트는 편한데 이래도 될까?
- foreign key가 있으면 foreign key가 존재하는지에 대한 검증을 하지 않아도 된다는 장점이 있다.
- 그러면 foreign key를 믿을 것인가?
- foreign key가 있다가 없어질 수 있나? 그렇다면 foreign key가 있더라도 검증을 하는 게 맞을 듯하다. 그런데 DB 설계가 수정되는 일이 많을까?
- 도메인에 id가 있어도 될까?
- 일단 id가 있으면 너무 편하다. id를 찾기 위해 DB를 다시 확인하는 일이 없어도 된다.
- DB 의존적이라고 생각한다.
- 모든 상황을 고려해서 예외 처리해야 할까?
- 언제나 쓰는 곳이 정해져 있는데 그렇지 않은 경우를 상정하고 예외처리할 것인가?
- 여러 개 추가될 때 어떤 값을 Location에 적어야 할까? 정말 전달하지 않는 것만이 최선이었을까?
- dao 테스트 굳이 필요한가. 너무 복붙 코드고(대부분의 dao 테스트가 유사한 코드를 작성하게 된다) 의미가 없는 느낌이다.
- 어쩔 수 없이 실제 DB를 사용하기 위해서는 save 메서드에 의존하게 되는데 이렇게 dao 테스트 하는 게 맞을까?
- 도메인을 굳이 만들었어야 했을까? 사실 서비스에서 다 할 수 있는데 객체지향을 위해 도메인을 추가한 느낌?
- 조인 vs 여러 번의 쿼리 중에 언제나 조인이 좋을까?
1단계 미션에서 고민했던 것
객체 설계 방법과 그 이유
Line 안에 Sections가 있고, Section은 시작역과 도착역, 거리를 저장한다. Station은 역 이름을 저장한다.모든 Station에 종점인지 확인하기 위한 필드를 둘지 고민했다. 계산할 때는 편하지만 의미없는 데이터들이 많이 생길 것 같아 이런 설계를 고안하게 되었다.
장점: 의미 없는 데이터가 없다. 종점을 저장하는 것은 종점이 바뀔때마다 데이터가 변경되어야 하므로 데이터 안정성이 떨어진다.
단점: 종점을 찾는 로직을 설계하는게 어려웠다.
테이블 설계 방법과 그 이유
station 테이블은 id, 이름, line_id를 갖는다. section 테이블은 id, 시작역_id, 도착역_id, 거리, line_id를 갖는다. line 테이블은 id와 이름을 갖는다.객체 설계와 유사하게 테이블을 구성했다.
station이 여러 line에 존재할 수 있기 때문에 line_id를 갖도록 했다.
API 설계 방법과 그 이유
노선 추가, 전체 노선과 역 조회, 특정 노선과 역 조회, 역 추가, 역 삭제하는 API를 설계했다.요구사항을 만족하는 기능만 구현했다.
시간이 부족했다. 역 조회, 역 목록 조회가 뼈대 코드에는 있었는데 노선 조회나 역 CREATE에서 역 id를 리턴하지 않아 클라이언트가 역 id를 알 수 있는 방법이 없다. 따라서 역 DELETE에서 이름을 받아 삭제하도록 했다.장점은 딱히 없고 상황상 어쩔 수 없이 선택했다.
역을 추가할 때 역이 두 개가 한 번에 추가되는 경우가 있어 Location 헤더에 어떤 값을 전달해야 할 지 몰라서 id를 보내지 않았다. 또한 노선 조회에서 역 id를 찾으려면 N번 쿼리를 보내야 했기 때문에 성능상 전달할 수 없었다.
단점: http 컨벤션에 맞지 않는 API다. id는 index 처리가 되어 있지만 이름은 index 처리가 되어 있지 않아 쿼리 속도가 느리다.
설계 과정에서 가장 고민을 많이 했던 부분
- 종점 찾는 로직
- 객체지향을 어떻게 지킬까
- 노선을 생성만 하면 역이 어떻게 알아서 정렬되게 할까