final project -day2-

Lee Dong Uk·2023년 6월 13일
0

오늘 진행한 것들


  • 이벤트 스토밍 결과(DDD 구현) 피드백 받기
  • 피드백 후 수정
  • API 명세서 작성
  • ERD 작성

이벤트 스토밍 결과 및 기능·인프라 요구사항 피드백


이전에 작성했었던 이벤트 스토밍 결과

피드백

  1. 이벤트 스토밍

우리가 작성했던 것들은 DDD라 보기 힘들다. DDD는 조직구조를 반영한다. (ERD랑은 다릅니다)

  • 애그리거트가 없다
  • 조직단위 바운디드 컨텍스트가 아니다
    • 바운디드 컨텍스트라면 배송관리팀, 결제관리팀, 제품관리팀, 시스템관리팀 으로 나누어져있어야 하는 것
  1. 기능·인프라 요구사항 피드백

기능·인프라 요구사항들이 너무 방대하다. 주어진 기안 내에 다 하지 못할 뿐더러, 현재 상황에선 손도 못댈 것들이 많다. (PG모듈 같은 것들...)

수정된 DDD

수정된 기능 요구사항

  • 판매자가 크라우드펀딩 제품을 오픈하고 펀딩을 받는다
  • 후원자가 프로젝트에 일정 금액을 펀딩한다
  • 목표 금액이 달성되면, 해당 프로젝트는 성공으로 간주한다 (판매자가 제품을 만들고 배송하는 것은 부차적인 것)

수정된 인프라 요구사항

  • 컨테이너 베이스 구현

  • 데이터베이스를 쓰는데, 목적에 맞게 선정이 필요

    • 프로젝트 CRUD: 어떤 종류의 데이터베이스를 써도 상관이 없음
    • 결제 -> 결제 시도 및 결과와 관련한 이벤트 로그가 항상 있어야 한다. (후원자의 트랜잭션, 프로젝트에 쌓인 트랜잭션이 일치할 수 있도록, 최종적 일관성만 확보되면 됨)
      • mq가 로그 저장소의 역할도 하니까 고려해보시면 좋을 듯하다
      • 바로 결제시스템을 연결하기보다는 (강결합 x), 일종의 사이버머니(포인트)가 트랜잭션 상에서 왔다갔다 하는게 구현도 편하고, 테스트도 편하고, 컨셉 증명도 편하다. (확장성에도 좋음)
  • 가용성

    • 가장 빈번한 트래픽 발생은 어디서 발생할까?: 상품 후원 -> 결제 쪽 데이터베이스에 가용성 확보 전략을 마련해야 할듯하다.
    • API Server도 이중화 시키고 로드밸런서는 붙여야할듯.
  • 보안부분은 아키텍쳐 회의때 진행하기로함.

  • 모니터링

    • 무엇을 모니터링할 것인가?
      • 프로젝트 별 후원 상태
      • 결제 시도 시 실패가 어디에서 발생하는지
      • 4xx 5xx 에러

그 외

  • 결제는 필연적으로 외부 시스템과 연동이 되어야 하는 것
    • 트랜잭션 기록은 항상 실패에 대비해 구현해야 하고
    • 외부 시스템의 의존성 문제도 생각해야 한다.


기존에 생각하고 작성했던 부분들(DDD)에 대한 개념정리가 확실하지 않았었다.
사실 아직도 잘 모르겠다.

0개의 댓글