들어가며
야구 직관 서비스 캐치미 프로젝트에서 실시간 채팅 서비스를 구현한 내용을 기록 및 복습의 목적으로 본 글을 포스팅합니다. 이번 포스팅에서는 캐치미 채팅 서비스의 도메인 규칙에 따라 채팅 데이터베이스를 설계한 경험을 다뤄보려고 합니다. 소켓과 웹소켓, STOMP 프로토콜에 대한 개념, HTTP 통신과의 차이점의 차이점을 알고 싶은 분은 이전 글을 참고해 주세요!
[Spring boot] WebSocket 을 사용하여 채팅 시스템 구현하기(1) - 웹소켓(WebSocket), STOMP 이해하기
들어가며야구 직관 서비스 캐치미 프로젝트에서 실시간 채팅 서비스를 구현한 내용을 기록 및 복습의 목적으로 본 글을 포스팅합니다. 이번 포스팅에서는 소켓과 웹소켓, STOMP 프로토콜에 대한
tenaciously.tistory.com
도메인 규칙 살펴보기
우리 팀은 기능 개발을 시작하기 전 각자 맡은 도메인에 대한 도메인 규칙을 작성하기로 정했습니다.
여기서 도메인 규칙이란 뭘까 ?
도메인 규칙이란 도메인 모델이 반드시 준수해야 하는 비즈니스 규칙이나 제약사항을 의미한다.
이는 도메인 모델의 상태와 동작을 정의하는 기준으로, 시스템이 비즈니스적으로 올바르게 동작하도록 보장하는 핵심 로직이다.
이러한 도메인 규칙은 ERD를 설계하기 전 도메인 규칙을 작성하는 것은 시스템 설계와 개발 과정에서 상당히 많은 이점을 제공합니다.
기획 단계에서 다른 팀원들과 정한 비즈니스 요구사항을 반영하여 도메인 규칙을 작성하는 과정에서 어떠한 데이터가 필요한 지, 데이터 구조는 어떻게 짜야하는지 명확하게 이해할 수 있습니다.
예를 들어, 제약 사항을 사전에 정의함으로써 테이블 설계 시 NOT NULL, UNIQUE와 같은 제약 조건을 쉽게 정할 수 있고, 테이블 간의 연관 관계를 더 직관적으로 파악할 수 있습니다.
또한 나는 단위 테스트를 작성할 때도 도움을 받았는데, 도메인 규칙을 통해 제약 조건 및 동작이 잘 설계된 엔티티가 완성됐다면, 단위 테스트 작성 시 예상 가능한 예외 발생 시나리오를 구체적으로 설계할 수 있어 더욱 꼼꼼하게 테스트 코드를 작성할 수 있었습니다.
예시 - 쇼핑몰 도메인 규칙
아래는 쇼핑몰 도메인을 설계할 때 작성된 도메인 규칙의 예시입니다.
고객은 이메일을 반드시 제공해야 한다.
-> Member 테이블의 email 필드는 NOT NULL로 설계
각 주문은 하나 이상의 상품을 포함해야 한다.
-> Order 테이블과 Item 테이블의 관계는 N:M으로 설계하거나, 이를 연결하는 Order_Item 테이블이 필요
상품의 재고는 0 미만으로 내려갈 수 없다.
-> Item 테이블의 stock_quantity 필드는 0 이상의 값만 허용
주문 상태는 “결제 대기”, “결제 완료”, “배송 중”, “배송 완료” 중 하나여야 한다.
-> Order 테이블의 status 필드는 ENUM 또는 별도의 상태 테이블로 관리
이렇게 작성된 도메인 규칙을 반영한 ERD를 설계한다면 요구사항의 변화나 확장성을 고려하여 더욱 유연한 구조로 설계가 가능하다.
아래는 실제 프로젝트에서 작성했었던 채팅 관련 도메인 규칙입니다.
채팅 ERD 설계
📱 채팅방(chat_room)
- 판매글 ID: 판매글 하나당 여러 개의 채팅방을 가질 수 있으므로 1:N 관계를 가진다.
- 마지막 채팅 내용: 채팅방 목록 조회에서 데이터를 보여주기 위해 필요함
- 마지막 채팅 시간: 채팅방 목록 조회에서 정렬을 위해 필요함
- 채팅방 활성 여부: 채팅방에 한 명의 사용자만 남을 경우, 채팅방 비활성화에 필요하다. TINYINT(1)로 지정했다.
👨🏻💻 채팅 참여(chat_part)
채팅방과 회원의 관계는 N:M 관계이기 때문에 채팅 참여 테이블을 둘을 이어주는 연결 테이블로 생성하여, 1:N, N:1 관계로 설계했다.
- 회원 ID, 채팅방 ID: 채팅 참여의 PK로 복합키를 사용했다.
- 역할 : 판매자와 구매자를 구분하는 ENUM이다.
- 채팅방 퇴장 여부: 채팅방 목록 조회에서 데이터를 필터링에 필요하다. TINYINT(1) 타입으로 지정했다.
💬 채팅 메시지(chat_message)
- 회원 ID, 채팅방 ID: 채팅 참여 하나당 여러 개의 채팅 메시지를 가질 수 있으므로 1:N 관계를 가진다.
- 채팅 타입: 채팅 종류를 구분하기 위한 ENUM이다.
마치며
이번 포스팅에서는 캐치미 프로젝트의 채팅 서비스 구현을 위한 도메인 규칙과 ERD 설계 과정을 살펴보았습니다. 도메인 규칙을 명확히 정의함으로써 데이터베이스 설계의 방향성을 잡고, 비즈니스 요구사항을 충족하는 구조를 만들 수 있었습니다.
채팅 서비스는 사용자 간의 실시간 소통을 가능하게 하는 중요한 기능으로, 이를 위해서는 안정적이고 효율적인 데이터 구조가 필수적입니다. 채팅방, 채팅 참여, 채팅 메시지와 같은 주요 엔티티를 정의하고, 이들 간의 관계를 명확히 할 수 있었습니다.
채팅 ERD를 설계할 때 도움이 되었던 유튜브 링크를 첨부하며 마칩니다. 감사합니다 :)
[Spring boot] WebSocket 을 사용하여 채팅 서비스 구현하기(3) - STOMP를 사용하여 실시간 채팅 구현 (비
들어가며야구 직관 서비스 캐치미 프로젝트에서 실시간 채팅 서비스를 구현한 내용을 기록 및 복습의 목적으로 본 글을 포스팅합니다. 이번 포스팅에서는 STOMP 프로토콜과 스프링 내장 메시지
tenaciously.tistory.com
'Back-End > Spring' 카테고리의 다른 글
[Spring boot] Redis Cache를 적용한 조회 성능 개선 (0) | 2025.01.31 |
---|---|
[Spring boot] No Offset 적용한 페이징 성능 개선 - MongoDB (2) | 2025.01.29 |
[Spring boot] MySQL → MongoDB 마이그레이션 과정 (0) | 2025.01.27 |
[Spring boot] WebSocket 을 사용하여 채팅 서비스 구현하기(3) - STOMP를 사용하여 실시간 채팅 구현 (비동기 처리) (2) | 2025.01.21 |
[Spring boot] WebSocket 을 사용하여 채팅 서비스 구현하기(1) - 웹소켓(WebSocket), STOMP 이해하기 (1) | 2025.01.13 |