오늘 진행한 것들
- 이벤트 스토밍 결과(DDD 구현) 피드백 받기
- 피드백 후 수정
- API 명세서 작성
- ERD 작성
이벤트 스토밍 결과 및 기능·인프라 요구사항 피드백
이전에 작성했었던 이벤트 스토밍 결과
피드백
- 이벤트 스토밍
우리가 작성했던 것들은 DDD라 보기 힘들다. DDD는 조직구조를 반영한다. (ERD랑은 다릅니다)
- 애그리거트가 없다
- 조직단위 바운디드 컨텍스트가 아니다
- 바운디드 컨텍스트라면 배송관리팀, 결제관리팀, 제품관리팀, 시스템관리팀 으로 나누어져있어야 하는 것
- 기능·인프라 요구사항 피드백
기능·인프라 요구사항들이 너무 방대하다. 주어진 기안 내에 다 하지 못할 뿐더러, 현재 상황에선 손도 못댈 것들이 많다. (PG모듈 같은 것들...)
수정된 DDD
수정된 기능 요구사항
- 판매자가 크라우드펀딩 제품을 오픈하고 펀딩을 받는다
- 후원자가 프로젝트에 일정 금액을 펀딩한다
- 목표 금액이 달성되면, 해당 프로젝트는 성공으로 간주한다 (판매자가 제품을 만들고 배송하는 것은 부차적인 것)
수정된 인프라 요구사항
-
컨테이너 베이스 구현
-
데이터베이스를 쓰는데, 목적에 맞게 선정이 필요
- 프로젝트 CRUD: 어떤 종류의 데이터베이스를 써도 상관이 없음
- 결제 -> 결제 시도 및 결과와 관련한 이벤트 로그가 항상 있어야 한다. (후원자의 트랜잭션, 프로젝트에 쌓인 트랜잭션이 일치할 수 있도록, 최종적 일관성만 확보되면 됨)
- mq가 로그 저장소의 역할도 하니까 고려해보시면 좋을 듯하다
- 바로 결제시스템을 연결하기보다는 (강결합 x), 일종의 사이버머니(포인트)가 트랜잭션 상에서 왔다갔다 하는게 구현도 편하고, 테스트도 편하고, 컨셉 증명도 편하다. (확장성에도 좋음)
-
가용성
- 가장 빈번한 트래픽 발생은 어디서 발생할까?: 상품 후원 -> 결제 쪽 데이터베이스에 가용성 확보 전략을 마련해야 할듯하다.
- API Server도 이중화 시키고 로드밸런서는 붙여야할듯.
-
보안부분은 아키텍쳐 회의때 진행하기로함.
-
모니터링
- 무엇을 모니터링할 것인가?
- 프로젝트 별 후원 상태
- 결제 시도 시 실패가 어디에서 발생하는지
- 4xx 5xx 에러
- 무엇을 모니터링할 것인가?
그 외
- 결제는 필연적으로 외부 시스템과 연동이 되어야 하는 것
- 트랜잭션 기록은 항상 실패에 대비해 구현해야 하고
- 외부 시스템의 의존성 문제도 생각해야 한다.
기존에 생각하고 작성했던 부분들(DDD)에 대한 개념정리가 확실하지 않았었다.
사실 아직도 잘 모르겠다.
