이번 수업은 DB에 관한 것이었다. 로우스토어와 컬럼스토어는 두 번째 보는 것 같은데 기억해두자. 클러스터링 인덱스가 전체적인 내용이었는데, 인덱스 페이지와 데이터 페이지를 합쳐 부르는 것이라 하면 된다고 한다.
나열해보니 아이템이 많다.
작성했던 테스트코드 리뷰를 받았다. 요는 컨트롤러는 인수테스트가 더 어울린다는 것. 맞는 것 같다. 그래서 다 고쳤다.
인수 테스트에는 RestAssured와 TestRestTemplate이 많이 쓰이는데, 후자가 스프링 기본이라 사용했다. 그런데 RestAssured를 더 많이 사용하는 것 같다. 대충 보니 더 편하게 만들어져있는 것 같다. TestRestTemplate은 파라미터 매핑이 조금 귀찮다. 코가 vs 펩시와 비슷한 구도라고... 일단은 써보고 나중에 느껴보기로 했다.
고치면서 이해가 잘 안 갔던 부분은 RestTemplate에 객체나 맵으로 쿼리 파라미터를 넣으라고 시키면 넣어주지 않았던 점이다. 알고보니 ?param={value}와 같은 식으로 매핑시켜줘야 하는 것이었다. 그래서 그냥 그만뒀다.
한 가지 염려는 컨트롤러에서 모델 매핑을 시켜놔서 쿼리스트링임에도 스웨거에는 오브젝트로 보인다는 점. 물론 object(query)라고 적혀있긴한데 조금 찝찝하다. 그런데 어떻게 방법은 없는 것 같다. 아예 어노테이션으로 다 붙여줘야하나?
이외에도 리뷰 내용 중에 스프링 프로필을 이용해서 목업과 도메인을 분리 시킬 수 있다는 피드백이 있었는데, 무슨 말인지 이해가 안 된다. 잘 정리해서 질문해봐야지..
조프로님 강의는 좋았다. 책으로는 와닿지 않았던 중요한 부분들을 잘 풀어주신 것 같다. 어제 책임이 가장 중요한 것 같다고 TIL에 써놨는데 조영호님도 책임이 가장 중요하다 하시니 책을 잘 읽은 것 같아 기분이 좋았다. 근데 책임 주도 설계이니 당연한거겠지?
발표 내용은 책임, 역할, 협력의 사이클이 핵심이었던 것 같다. 그 외의 여러가지 부분이 있었는데, 정리해둔거 바탕으로 데브독스를 써봐야겠다. 너무 길어지면 이 정도로 끊으면 되겠다는 기준이 어느정도 생겼으니 주제로 충분할 것 같다.
다음 집은 무조건 주차장과 CCTV가 있는 곳으로 간다. 그러니까 열심히좀 하자~...
적당히 작성한 이유는 막상 서비스 테스트를 작성하려고 생각해보니 레포지토리와 독립적으로 진행해야 할 것 같다는 생각이 들었기 때문이다. 브라이언이 리뷰에 남겨줬던 프로필과 관련된 것이 이 부분 아닌가 싶다. 같은 이유로 서비스는 인터페이스로 바꾸고 목업과 도메인 개발용 구현체들을 만들어줬다.
DB설계를 하며 도메인 로직과 DTO의 관계를 생각해보니 각각을 한 번에 생각하려고 했던 것이 그 간의 잘못된 점 아닌가 하는 생각이 들었다. 컨트롤러와 연결되는 DTO는 다른 영역이지만, 테이블과 객체가 맞지 않는 문제점을 해결하기 위한 방법이 ORM이다. 그런데 Data JDBC나 쿼리매퍼들은 부자연스러운 부분이 생긴다. 그러면 이 부분을 직접 매핑해줘야 좀 더 좋은 객체 설계가 나올 수 있는게 아닌가 싶다.
그래서 현재 목표는 DB와 앱서버 간의 엔드포인트를 이어줄 엔티티 객체와 서비스 로직을 담당할 도메인 객체를 분리해서 작성하려고 한다. 그러면 서비스는 레포지토리와 느슨해지기때문에 편하게 단위테스트 작성이 가능해진다. 단점은 당연히 시간과 정성이다... 그런데 이렇게 하지 않으면 야구게임 프로젝트와 같은 대참사가 발생할 것 같다. 다음주에 최대한 빨리 끝내버리자.
알고리즘
Powered with by Gatsby 2.0