- 나: 실무에서 도메인 구성/분리는 어떻게 하는가?
- 멘토: 회사, 팀마다 케바케다. 기준도 다르고 패키지 구조도 다 다르다.
- 멘토: 처음에는 어떤 기준이 있어서 잘 분리했겠지만, 기능이 추가되고 변경되며 다 꼬인다.
- 멘토: 그럼 누군가가 총대 매고 리팩토링하고, 다시 품질이 나빠지고... 계속 반복된다.
- 멘토: 그래서 도메인이 어떤 (좋든 나쁘던) 기준으로 분리되었느냐보다는 정해진 기준을 잘 지키느냐가 훨씬 중요하다.
- 나: 지금 프로젝트에서 도메인 구성/분리는 어떻게 해야 할까? 나는 의존성 관점에서 구상했는데, 지금 구현하려는 기능만 해도 6개 정도이다. 너무 많은 것 아닌가?
- 멘토: 구상 그대로 진행해도 좋을 것 같다.
- 멘토: 다른 도메인에 종속적이지 않은 도메인은 분리를 하는게 좋다.(의존성 관점에서 무언가가 없어도 홀로서 존재할 수 있는 것 들)
- 나: 앞으로 구현할 검색 기능 같은 경우, 여러 도메인의 기능을 사용해야 한다. 어떤 도메인(정확히는 패키지)에 위치해야 하는가?
- 멘토: 일반적으로 검색 기능을 모아두는 패키지로 따로 분리를 하는 경우가 많다.
- 나: DB 테이블에서 create_at, update_at 같은 건 꼭 사용하는가?
- 멘토: 그렇다. 일단 제공해 준 설명처럼 나중에 추가해도 의미가 없기도 하고, 안 쓰는 경우가 거의 없다. 필드 몇 개 추가한다고 성능에 큰 영향이 주는 것도 아니기도 하다.
- 멘토: 그리고 이러한 설정을 개발자가 하는게 아니라 시스템적으로 적용되게 설정되어 있는 경우도 있다. 그래서 필요 없는 경우에도 이런 필드가 붙어있는 경우도 있다.
- 나: 그럼 이러한 audit 값은 어플리케이션 단, DB 단 둘 다 구현 가능하던데 어디서 하는가?
- 멘토: 요즘에는 DB에 어떤 연산을 최소화하려고 하기 때문에 어플리케이션 단에서 구현한다.
- 멘토: DB는 스케일 아웃이 어려운데, 어플리케이션은 쉽기 때문이다.
- 멘토: 그 외에 버전 태그나 Revision History(이력성 테이블과 비슷한 의미)도 있다.
- 나: snowflake나 obejctID 처럼 시간 정보를 포함하는 경우에는 create_at을 사용하지 않는가?
- 멘토: 그래도 create_at을 사용한다. snowflake나 obejctID같은 건 분산 서비스에서 시간 순 정렬을 위해서 사용하는 거고, 그것과 별개로 create_at도 필요하다.
- (DB가 하나인 경우에는 long을 사용해도 문제 없으니까)
- 나: 실무에선 거의 soft delete을 사용하는가?
- 멘토: 사실 상 무조건이라고 봐도 된다. 최소한 사용자가 삭제를 요청했을 때, 데이터가 바로 삭제되는 경우는 거의 없다.
- 멘토: 가장 큰 이유는 법적으로 데이터를 몇 년간 보관해야 하기 때문도 있고, 또 hard delete는 성능이 좋지 않기 때문이다.
- 나: 그럼 실제 데이터 삭제는 언제 이루어지는가?
- 멘토: 회사마다 다르지만 통계를 위해서 계속 보관하는 경우도 있고, 배치를 돌려서 제거하는 경우도 있다.
- 나: 클라우드 스토리지의 데이터들은 어떻게 관리하고 삭제되는가?
- (위에서 말한 soft delete와 내용이 비슷해서 셍랙)
- 나: post 테이블의 content에서 마크다운 자체를 저장한다. 그래서 인스트와 같이 이미지와 설명이 따로 있는게 아닌데, 굳이 post_image 테이블을 사용할 필요가 있다.
- 멘토: 멘티의 프로젝트의 경우에는 굳이 사용할 필요는 없다. 다만 멘티 프로젝트 같은 경우에도 데이터 관리를 위해서 사용하기도 한다.
- 멘토: 데이터를 삭제하는 경우에 이미지에 대한 처리를 하려면 content를 파싱해서 url을 구해야 하는 과정이 필요하기 때문이다.
- 나: (멘토가 동기 비동기 차이를 물어봄, 내가 잘 대답하지 못함) 동기와 비동기의 차이를 설명하기가 어렵네요.
- 멘토: 간단하게 내가 어떤 걸 호출하고 내가 처리하는가(동기) 남이 처리하는가(비동기)의 차이로 볼 수 있다.
- 멘토: 멘티가 방금 순서 보장 관련해서 이야기를 했는데, 그건 동기/비동기의 특징 때문에 나오는 결과의 차이이다.
- 멘토: 알림 기능을 비동기로 구현해야 하는 이유가...
- 멘토: 알림 기능 같은 경우에는 스케일링을 위해서 비동기를 쓴다.
- 멘토: 스프링 이벤트 같은 경우는 비동기긴 하지만 결국 로컬 머신의 자원을 사용하므로 스케일링 관점에서는 별 차이가 없다. 물론 api 응답 시간에는 차이가 있을 수 있지만, 스케일링 관점에서 보면 아무 의미 없다.
- 멘토: 다만 위 말은 email이나 sms에 알림을 보내거나 하는 경우고, 지금 구현은 동기로 구현해도 상관 없다.
- (내 정리: 메시징 서비스나 푸시 알림 서비스를 이용하면 더 빠르고 안정적으로 알림을 전달할 수 있다. 이러한 서비스는 보통 스케일 아웃이 쉽게 가능하므로, 알림의 양에 따라 쉽게 대응할 수 있지만, 스프링 이벤트 방식은 그렇지 않다.)
- 멘토: 메인 페이지에서 추천하는 글이나, 글 조회 페이지 하단에 추천하는 글은 어떤 기준으로 보여지는가?
- 나: 지금 당장은 최신 순이나, 북마크 만은 순으로 제공하려고 한다. 시간이 된다면 추천 알고리즘을 사용해 볼 생각이 있다.
- 멘토: "서로이웃이나 나만 볼 수 있는 글" 같은 기능은 지원하는가?
- 나: 임시 작성 글을 통해서 나만 볼 수 있게 기획하긴 했는데, 서로이웃 같은 건 나중에 시간이 된다면 추가할 수 있도록 하겠다.
- post_image 테이블 삭제
- erd 수정