mirror of
https://github.com/hwanny1128/HGZero.git
synced 2025-12-06 07:56:24 +00:00
909025aa27
- 총 21개 PlantUML 파일 생성 (Meeting 10개, AI 6개, STT 2개, Notification 3개) - 서브 에이전트를 활용한 병렬 설계로 효율성 극대화 - 모든 시나리오는 유저스토리 및 외부 시퀀스와 1:1 매칭 - Controller → Service → Repository 계층 구조 명확히 표현 - Redis Cache, Azure Event Hubs 등 인프라 컴포넌트 표시 - 동기(→)/비동기(-->) 구분 명확 - 외부 참여자 <<E>> 표시 적용 - PlantUML 문법 검사 및 오류 수정 완료 (13개 파일 수정) - par/and 블록 문법 오류 수정 - return 형식 적용으로 참여자 없는 화살표 오류 해결 설계 특징: - 캐시 전략: Cache-Aside 패턴, TTL 관리, 즉시 무효화 - 비동기 처리: Azure Event Hubs 기반 이벤트 구독 - 실시간 협업: WebSocket 기반 동기화, 변경 델타 전송 - 데이터 일관성: 버전 관리, 양방향 연결, 트랜잭션 처리 추가 파일: - claude/sequence-inner-design.md: 내부시퀀스설계 가이드 - tools/check-plantuml.ps1: PlantUML 문법 검사 스크립트 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
278 lines
8.8 KiB
Markdown
278 lines
8.8 KiB
Markdown
# 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
|