# Meeting Service 내부 시퀀스 설계

Meeting Service의 내부 처리 흐름을 표현한 시퀀스 설계서 모음입니다.

## 📋 설계 개요

### 목적
- Meeting Service 내부의 Controller → Service → Repository 계층 구조 표현
- 각 시나리오별 비즈니스 로직 및 데이터 처리 흐름 상세화
- 캐시, 데이터베이스, 메시징 인프라와의 상호작용 명시
- 동기/비동기 처리 구분 명확화

### 설계 원칙
- **유저스토리 기반**: 모든 시나리오는 유저스토리와 1:1 매칭
- **외부 시퀀스 일치**: 외부 시퀀스 설계와 일관성 유지
- **계층 구조 명확화**: Controller, Service, Repository 역할 분리
- **인프라 표시**: DB, Cache, Event Hub 등 외부 참여자는 <<E>> 표시
- **비즈니스 로직 설명**: note를 통한 핵심 로직 설명

## 📂 시나리오별 설계 파일

### 1. 대시보드 조회
**파일**: `meeting-대시보드조회.puml`
**유저스토리**: AFR-USER-020
**주요 처리**:
- 사용자별 대시보드 정보 조회 (예정된 회의, Todo, 최근 회의록, 공유받은 회의록)
- Redis 캐시 우선 조회 (Cache-Aside 패턴)
- 통계 정보 계산 (예정 회의 수, Todo 완료율)
- 응답 데이터 TTL: 5분

**주요 컴포넌트**:
- DashboardController
- DashboardService
- MeetingRepository, TodoRepository, MinutesRepository
- Redis Cache, Meeting DB

---

### 2. 회의 예약
**파일**: `meeting-회의예약.puml`
**유저스토리**: UFR-MEET-010
**주요 처리**:
- 회의 정보 입력 검증 (제목, 날짜/시간, 참석자)
- 중복 회의 체크 (같은 시간대 회의 확인)
- 회의 및 참석자 정보 저장
- 캐시 저장 (회의 정보, 참석자 목록)
- 비동기 이벤트 발행 (MeetingCreated)

**주요 컴포넌트**:
- MeetingController
- MeetingService
- MeetingRepository, ParticipantRepository
- Meeting DB, Redis Cache
- Azure Event Hubs (비동기 알림)

---

### 3. 회의 시작
**파일**: `meeting-회의시작.puml`
**유저스토리**: UFR-MEET-030
**주요 처리**:
- 회의 시작 권한 검증 (생성자 또는 참석자)
- 회의 상태 확인 (SCHEDULED → IN_PROGRESS)
- 회의 세션 생성 (sessionId, startedAt)
- 회의록 초안 생성 (빈 회의록)
- 비동기 이벤트 발행 (MeetingStarted → STT 녹음 시작)

**주요 컴포넌트**:
- MeetingController
- MeetingService, SessionService
- MeetingRepository, SessionRepository
- Meeting DB, Redis Cache
- Azure Event Hubs (STT 연동)

---

### 4. 회의 종료
**파일**: `meeting-회의종료.puml`
**유저스토리**: UFR-MEET-040
**주요 처리**:
- 회의 종료 권한 검증 (생성자만)
- 회의 세션 종료 (endedAt 기록)
- 회의 상태 변경 (IN_PROGRESS → ENDED)
- 회의 통계 생성 (총 시간, 참석자 수, 발언 횟수)
- 회의록 상태 업데이트 (DRAFT)
- 비동기 이벤트 발행 (MeetingEnded → AI 최종 회의록 생성)

**주요 컴포넌트**:
- MeetingController
- MeetingService, SessionService, StatisticsService
- MeetingRepository, SessionRepository
- Meeting DB, Redis Cache
- Azure Event Hubs (AI 연동)

---

### 5. 회의록 확정
**파일**: `meeting-회의록확정.puml`
**유저스토리**: UFR-MEET-050
**주요 처리**:
- 회의록 확정 권한 검증 (생성자만)
- 필수 항목 검증 (제목, 참석자, 논의 내용, 결정 사항)
- 확정 버전 생성 (v1.0)
- 회의록 스냅샷 저장 (버전 관리)
- 회의록 상태 변경 (DRAFT → FINALIZED)
- 비동기 이벤트 발행 (MinutesFinalized → AI Todo 추출)

**주요 컴포넌트**:
- MinutesController
- MinutesService, ValidationService
- MinutesRepository
- Meeting DB, Redis Cache
- Azure Event Hubs (AI Todo 추출)

---

### 6. 회의록 상세 조회
**파일**: `meeting-회의록상세조회.puml`
**유저스토리**: UFR-MEET-047
**주요 처리**:
- 회의록 조회 권한 검증 (생성자, 참석자, 공유받은 사용자)
- Redis 캐시 우선 조회 (Cache-Aside 패턴)
- 회의록 기본 정보 + 참석자 + 섹션 + AI 요약 조회
- 관련 회의록 조회 (벡터 유사도 기반, 최대 3개)
- 조회 이력 기록
- 응답 데이터 TTL: 10분

**주요 컴포넌트**:
- MinutesController
- MinutesService, RelatedMinutesService
- MinutesRepository, SectionRepository
- Meeting DB, Redis Cache

---

### 7. 회의록 수정
**파일**: `meeting-회의록수정.puml`
**유저스토리**: UFR-MEET-055
**주요 처리**:
- 회의록 수정 권한 검증 (생성자만)
- 잠긴 섹션 수정 여부 확인
- 수정 이력 저장 (버전 관리)
- 회의록 제목 및 섹션 내용 수정
- 확정된 회의록은 DRAFT로 상태 변경
- 실시간 동기화 (WebSocket 브로드캐스트)
- 캐시 무효화

**주요 컴포넌트**:
- MinutesController
- MinutesService, VersionService, CollaborationService
- MinutesRepository, SectionRepository
- Meeting DB, Redis Cache
- WebSocket (실시간 협업)

---

### 8. 회의록 공유
**파일**: `meeting-회의록공유.puml`
**유저스토리**: UFR-MEET-060
**주요 처리**:
- 회의록 공유 권한 검증 (생성자만)
- 회의록 상태 확인 (FINALIZED만 공유 가능)
- 공유 링크 생성 (UUID 기반 토큰)
- 공유 대상 및 권한 설정 (READ_ONLY, COMMENT, EDIT)
- 다음 회의 일정 추출 및 캘린더 등록
- 비동기 이벤트 발행 (MinutesShared → 이메일 알림)

**주요 컴포넌트**:
- ShareController
- ShareService, CalendarService
- MinutesRepository, ShareRepository
- Meeting DB, Redis Cache
- Azure Event Hubs (알림 발송)

---

### 9. Todo 할당
**파일**: `meeting-Todo할당.puml`
**유저스토리**: UFR-TODO-010
**주요 처리**:
- Todo 정보 입력 검증 (내용, 담당자, 회의록 ID)
- 회의록 존재 확인
- Todo 생성 및 저장
- 회의록 섹션과 양방향 연결 (Todo 뱃지 추가)
- 마감일이 있는 경우 캘린더 이벤트 생성
- 비동기 이벤트 발행 (TodoAssigned → 담당자 알림)
- 캐시 무효화 (대시보드, 회의록)

**주요 컴포넌트**:
- TodoController
- TodoService, CalendarService
- TodoRepository, MinutesRepository
- Meeting DB, Redis Cache
- Azure Event Hubs (알림 발송)

---

### 10. Todo 완료 처리
**파일**: `meeting-Todo완료처리.puml`
**유저스토리**: UFR-TODO-030
**주요 처리**:
- Todo 완료 권한 검증 (담당자만)
- Todo 상태 변경 (IN_PROGRESS → COMPLETED)
- 회의록 섹션에 완료 상태 자동 반영
- 모든 Todo 완료 여부 확인
- 실시간 동기화 (WebSocket 브로드캐스트)
- 비동기 이벤트 발행 (TodoCompleted 또는 AllTodosCompleted)
- 캐시 무효화 (대시보드, 회의록)

**주요 컴포넌트**:
- TodoController
- TodoService, CollaborationService
- TodoRepository, MinutesRepository
- Meeting DB, Redis Cache
- WebSocket (실시간 협업)
- Azure Event Hubs (알림 발송)

---

## 🎯 설계 특징

### 1. 캐시 전략
- **Cache-Aside 패턴**: 캐시 우선 조회 후 DB 조회
- **TTL 설정**: 조회 데이터 5-10분, 회의 정보 10분
- **캐시 무효화**: 데이터 변경 시 즉시 삭제

### 2. 비동기 처리
- **이벤트 기반**: Azure Event Hubs를 통한 이벤트 발행
- **서비스 분리**: STT, AI, Notification 서비스와 비동기 통신
- **성능 최적화**: 장시간 작업은 비동기로 처리

### 3. 실시간 협업
- **WebSocket**: 회의록 수정 및 Todo 완료 시 실시간 동기화
- **변경 델타 전송**: 전체 데이터가 아닌 변경 부분만 전송
- **충돌 방지**: 버전 관리 및 잠금 기능

### 4. 권한 관리
- **역할 기반**: 생성자, 참석자, 공유받은 사용자 구분
- **작업별 권한**: 수정, 확정, 공유 등 작업별 권한 검증
- **섹션 잠금**: 검증 완료 섹션은 생성자만 잠금/해제

### 5. 데이터 일관성
- **버전 관리**: 회의록 수정 이력 및 스냅샷 저장
- **양방향 연결**: Todo와 회의록 섹션 간 양방향 링크
- **트랜잭션**: 관련 데이터는 동일 트랜잭션 내 처리

## 🔍 검증 사항

### PlantUML 문법
- ✅ `!theme mono` 사용
- ✅ 외부 참여자 `<<E>>` 표시
- ✅ 동기 호출 `→`, 비동기 호출 `-->`
- ✅ alt/loop/note 적절히 사용

### 유저스토리 일치
- ✅ 모든 시나리오가 유저스토리와 매칭
- ✅ 외부 시퀀스 설계와 일치
- ✅ UI/UX 설계의 사용자 플로우 반영

### 아키텍처 원칙
- ✅ 계층 구조 명확 (Controller → Service → Repository)
- ✅ 캐시 우선 전략 적용
- ✅ 비동기 처리 명확히 구분
- ✅ 비즈니스 로직 상세 설명

## 📝 다음 단계

1. **PlantUML 검증**: Docker 컨테이너 설정 후 문법 검사 실행
2. **클래스 설계**: 내부 시퀀스 기반 클래스 다이어그램 작성
3. **데이터 설계**: Repository 계층 기반 테이블 스키마 설계
4. **API 명세**: Controller 기반 OpenAPI 명세 작성

---

**작성일**: 2025-10-22
**작성자**: 길동 (아키텍트)
**버전**: v1.0