1. 오늘 학습한 내용
1.1. 뉴스피드 팀 프로젝트
1.1.1. 복합키 활용 여부에 대한 고민
제가 개발은 맡은 인터랙션 도메인에서는 게시글에 대한 좋아요 기능과 사용자 사이의 팔로우 기능이 핵심입니다. 좋아요와 팔로우를 저장하는 테이블 둘 다 Id를 제외하면 외래키 2개 로만 구성되어 있는 테이블 입니다.
외래키 2개를 복합키로 사용하면 중복된 요청을 데이터베이스 레벨에서 원천적으로 차단할 수 있습니다. 반면, 행의 Id를 단일 키로 사용하면 별도의 제약조건을 만들어줘야 합니다.
특히 다른 필드를 추가하는 등 확장성을 고려하면 단일 키 방식이 조금 더 마음이 가지만, 앞에서 언급한 복합 키의 방식의 확실한 장점인 중복 방지라는 점 때문에 고민이 됐습니다. 사용자의 이상 행동이나 네트워크나 인프라 레벨에서 생기는 문제도 어느 정도 차단할 수 있기 때문입니다.
| 항목 | 복합 키 | 단일 키 + 제약 조건 |
|---|---|---|
| 기본 키 | (profileId, postId) | likeId (auto-increment) |
| 유일성 보장 | 기본 키 제약조건으로 원천 보장 | 별도의 Unique 제약조건으로 보장 |
| ORM 편의성 | 다소 복잡함 (@IdClass 등 필요) | 매우 편리함 (표준 방식) |
| 데이터 무결성 | 매우 높음 (키 자체가 의미를 가짐) | 높음 (Unique 제약조건이 필수) |
| 유연성 | 낮음 (PK는 변경하기 어려움) | 높음 (PK와 데이터가 분리됨) |
그리고 게시글의 좋아요 개수를 게시글에서 별도의 필드로 관리하는 방식으로 구현하기로 했습니다. 따라서, 좋아요 개수의 정합성을 아주 중요한 비즈니스로는 다루지 않을 것이기 때문에 일단 확장성을 고려하여 단일 키 방식으로 개발해보기로 했습니다.
특히, 최근에는 단순 좋아요 뿐만 아니라 확인, 슬퍼요 등 다양한 상호작용을 게시글이나 댓글에 표현하는 것이 어느 정도 사실상 표준화되고 있기 때문입니다. 이 때 리액션 종류를 나타내는 컬럼을 추가하더라도 복합키 방식이라면, 사용자가 하나의 게시물에 하나의 표현만 할 수 있는 제약이 생깁니다.
추가적으로 학습을 위해 팔로우 기능은 복합키로 개발해볼 생각도 있습니다.
1.1.2. 도메인별로 나눠서 처음 프로젝트 개발을 시작할 때의 어려움
제가 맡은 기능은 상대적으로 다른 도메인들의 기본 CRUD 기능이 어느 정도 개발이 완료되면 개발하는 것이 수월한 편입니다. 그래도 아무 것도 안 할 수는 없어서, 테스트 코드 처럼 Mock방식으로 개발을 하려 했으나, 여러 가지 제약이 있었습니다.
Entity만 개발이 되어 있는 상태였는데, 제가 개발하고자 하는 도메인에서 다른 팀원분들의 도메인의 서비스에서 반환하는 DTO를 이용해야 하는 경우, 다른 팀원분들이 서비스의 메소드는 어떻게 개발할건지 그리고 엔티티의 생성자나 비지니스 관련 메소드는 어떤 이름과 인자를 가질 것인지까지 필요했습니다.
메소드 레벨까지 제가 미리 정의를 해서 알려드리는 건 시간 차이도 있고, 옳지 않다는 생각이 들었습니다. 그래서 인터페이스를 스스로 정의하고, 특정 값을 무조건 반환하는 구현체 레벨로 Mock 서비스와 엔티티를 만들다 보니 너무 많은 비용이 든다는 생각도 들었습니다.
특히 다른 도메인에 대해서는 Service 레벨에 의존하자고 컨벤션을 정했기 때문에, 당연히 서비스 레벨에서 역할은 명확히 구분할 수 있겠으나 서비스 레벨까지 Mock 구현체를 만들어야 했습니다. 공용으로 사용하는 서비스 계층을 인터페이스 레벨로 메소드까지 그리고 메소드가 반환하는 DTO 까지는 미리 합의를 하는 게 좋을지 고민입니다.
2. 더 알아볼 내용 / 다음에 할 내용
- 담당 도메인인 상호작용 도메인 이어서 개발