도메인 최종 (진짜진짜 최종)

Delivery Manager를 엔티티로 관리하고있었는데, 현재 구조에서 Role 타입구분 외에는 User와 별다른 특성이 없어 따로 관리하지 않는다.

User (Aggregate Root)
 ├── id (UUID)
 ├── username
 ├── password
 ├── email
 ├── slackId
 ├── Role (Value Object)
 │    └── MASTER | HUB_MANAGER | HUB_DELIVERY | COMPANY_DELIVERY | COMPANY_MANAGER
 └── Status (Value Object)
      └── PENDING | APPROVED | REJECTED

확장성을 고려한 프롬프트 영속관리를 할까?

AI (Aggregate Root)
 ├── id (UUID)
 ├── receiverId // 메시지 받는 사람
 ├── prompt // 요청 프롬프트 틀
 ├── generatedText // 응답 (생성) 내용
 ├── requesteAt // 언제 요청을 보냈는지
 ├── responseAt // 언제 응답(AI응답)이 생성되었는지
 └── inputPayload // 입력값(주문/배송 등..)
 
 AI의 용도 ?
 - 메시지 템플릿 <- 바꾸기 편하게, : prompt o
 
 - 최단경로 계산
 - 경로 계산후 해당 경로의 거리 합, 시간 <- 바꾸기 위험! 개발자 용도: prompt x
 

처음에 프롬프트 템플릿을 crud로 사용자가 (알림 관리자) 수정할 수 있어도 좋겠다 싶었지만 경로 계산이나 경로의 거리 합 등은 개발자만 수정해야 할 것 같아 prompt는 저장하지 않고,

생성된 응답 내용만 저장하기로 했다.

AI (Aggregate Root)
 ├── id (UUID)
 ├── receiverId // 메시지 받는 사람
 ├── generatedText // 응답 (생성) 내용
 ├── requesteAt // 언제 요청을 보냈는지
 ├── responseAt // 언제 응답(AI응답)이 생성되었는지
 └── inputPayload // 입력값(주문/배송 등..)

도메인별로 사용자가 다른 기능을 할때 각 컨텍스트엔 어느 정보가 있어야할까

그렇다면 각각 분리된 컨텍스트 사이에서 중복된 정보가 있을때는 어떻게 관리?

-> 분리된 컨텍스트끼리 데이터 정합성을 위해 이벤트 처리를 해야한다.

서비스 간 요청 흐름은 명세를 할까?

API 명세서를 쓰다가 서비스 간 요청 흐름도 명세서에 포함시켜야 하는지 궁금했다.

튜터님께서는 요청흐름 정도만 표현할 수 있는 다이어그램 정도만 있어도 된다고 하셨다.

MSA 를 쓰는 이유

작고(small), 단순하고(simple), 분리된(decoupled) 서비스

= 확장 가능하고(scaleable), 회복적이며 (resilient) 유연한(flexible) 애플리케이션을 만들기 위해 사용한다.

API 문서 작성

나는 사용자+인증 부분을 맡았다.