설계를 거의 마무리 했다. db모델링은 거의 할게 없었다.
설계 열심히 하는건 좋은데 시간이 촉박하니 빠르게 시작해야 하지 않느냐는 피드백이 있었고 맞는 말이라 오늘부터 바로 환경 설정을 시작했다.
도커로 디비를 올리다보니 제대로 연결이 안 되는 것들이 생겼다. 더군다나 깃헙액션도 제대로 돌아가지 않았는데, h2없는 환경이 오랜만이라 많이 헤메는 것 같다. 세팅을 대강 살펴봤고 내일 해볼 예정이다.
책을 얼추 다 봤다. 마지막은 이벤트 구현과 CQRS에 관한 것이었는데, 이벤트는 구현에 대한 내용이 대부분이고 CQRS는 간단하게 넘어갔다. 조영호님 글을 다시 보고 공부해봐야겠다. 이벤트 관한 부분은 구현해보면서 찾아봐야겠다.
설계를 발표했다. 전체적인 흐름은 맞지만 상태와 배치에서 애매한 부분이 있어 피드백을 받았다. 생각보다 많이 들어오셔서 좋은 말씀을 해주셨다 ㅋㅋㅋ
피드백 바았던 걸 참고해서 중요도에 따라서 반응이 빨라야 하는 부분과 느려도 괜찮은 부분을 나누는 식으로 접근했다. 예를 들어 과금을 막아야 하는 기능은 반응이 빨라야 하지만 과금이 진행되는 부분은 느려도 괜찮다. 어차피 과금은 계속 진행되는거니까. 이런 식으로 접근하니 풀에 어떤 데이터를 넣을지, 어떤 식으로 분리할지도 명확해졌다.
상태 부분이 헷갈렸는데 노출에 관한 상태와 소재 자체에 대한 상태가 섞여있는 것 같다고 한다. 일단 분리는 됐는데, 피드백을 더 받아봐야겠다.
테스트 환경은 깃헙 액션 위에서 컨테이너를 올릴 수 있어서 쉽게 해결했다.
스키마 설정과 테스트 공통 작성을 이어서 했는데, 테스트 시 어떤 방식을 사용할지 고민이 됐다. 개 객체 생성으로 확인하는 방식은 부작용이 있다는 것을 이미 알고 있기 때문에 최대한 피하려고 했다. 그래서 JSONObject를 사용하거나 직접 확인하는 방법을 고민했는데, 더 생각해봐야겠다.
이번 주는 객체와 인터페이스에 관한 것이었다.
전체적인 맥락에서 상속을 최대한 지양하도록 언어 설계를 한 것이 아닌가 하는 의견들이 나왔다.
백킹 필드를 나눈 것도 굳이 프로퍼티를 상속시켜야겠으면 인터페이스에 선언하고 각 구현체에서 정의해라는 느낌이다.
개인적으로는 프로퍼티를 가리고 싶으면 인터페이스를 써라는 느낌을 강하게 받았다. 그리고 객체에는 최대한의 편의성을 제공한다.
코틀린으로 토이프로젝트를 하나 만들어봐야 진짜 감이 올 것 같다.
인수테스트는 Map을 활용하기로 했다. JSON 구조가 비슷하면서도 다루기 쉬울 거라 생각했다.
조회 API를 작성했는데, 크게 어렵지는 않았다. 테스트 데이터를 삽입하는 부분에서 애를 먹었는데, 그냥 JPA 레포지토리를 활용하기로 했다. 지금은 최대한 간단하게 가는게 좋을 것 같다.
어제 발표하며 피드백 받았던 부분들을 보완해서 피드백을 받았다. 어제 생각했던 부분들이 대부분 비슷해보였지만, 상태쪽이 많이 어려웠다.
결국 일시정지를 분리하고 새롭게 생각을 해봤지만 개념이 잘 잡히지 않는 것 같다.
설계는 얼추 마무리 됐다. 애를 먹었던 상태는 어느 정도 정리가 됐는데, 상태를 고립시키는 것이 목적인 것 같다. 정해둔 방식 외에는 다른 방식으로는 해당 상태에 접근하지 못하도록 해서 관리하는 것이다.
객체를 행동 관점에서 생각해야 하는 것은 맞지만, 행동이 여러가지 시스템에 영향을 받는다면 비효율적이게 된다. 예를 들어, 특정 조건은 풀에 존재하는지 확인하고 특정 조건은 RDB에 존재하는지, 그리고 특정 조건은 로그 집계가 되었는지 여부에 따라, 배치가 돌았는지 등등을 하나의 객체에서 파악하려면 여러개의 시스템과 지속적으로 연결돼야 한다.
특정 동작 이후 상태가 변화하는 것이 보장된다면 그 상태만 보고도 알 수 있다. 이러면 상태 관리는 어려워지겠지만, 객체의 구현은 간단해진다.
이런 식으로 생각해보니 편해졌는데, 결국 중요한 점은 내가 정의해둔 상태를 다른 상태나 행동과 결합해서 생각하기 시작하면 복잡해진다. 그냥 상태는 정확히 특정 조건에서만 발동하도록하고, 특정 조건에 대한 판단 성공 여부에 따라 상태를 바꿔주는 식으로 생각하기로 했다.
그래서 여러방안을 생각해봤는데, 일단은 enum에서 동작하도록 하고 아예 테이블을 분리해버리는 방법으로 가보려고 한다. embedded를 활용해보려 헀지만, 원래 용도에 맞지 않는 듯 하다. 양방향 참조가 필요하기 때문이다. 좀 더 근본적으로는 그 사이에 객체가 하나 더 끼어야 하지만 일단은 이렇게 가보려 한다.
사놓고 읽지 않았던 코드라는 책을 보고 있다. 진짜 처음부터 가는데, 간만에 회로를 다시 보게 생겼다. 다른 급한걸 먼저 읽을지 그래도 이번에 읽고 치울지 고민 중이다.
Powered with by Gatsby 2.0