21 10 05 주문 도메인 미팅 회의록 (초안) - CodeSoom/DDD-Kurly-Clone-Order GitHub Wiki

Agenda

  • 리더

    • 덕수님 10.06 ~ 10.11

  • 기술 스택

    • JDK 16 탕탕
      • 올려놓고 쓰기 의문이다~
      • 점진적으로 하는게 좋지 않는가?
      • 16으로 결정하고 사용 하고 싶을 떄 사용한다.
    • JPA 사용할떄 queryDSL을 세팅하는게 좋지 않나?
      • 커스텀 레포 만들고 복잡한 쿼리가 있다면 queryDSL에 사용하면 좋지 않는가?
        • 많은 경험이 없어서 아직 결정 못함
        • 실제로 필요할때 만들어서 결정하자
        • query가 필요하다 싶으면 만들자.
        • 일단 올리자.
        • 기본적인 구성을 짜놓자.
    • 배포나 DB는 어떤걸...? 서버를 어디?
      • AWS/AUZRE/GCP? 어디
        • 10월 6일 다른 도메인 서버 분들에게 논의를 하는 것으로
    • RDS vs No SQL
      • MemoryDB로하다가 쉽게 갈아 탈 수 있다.
      • No SQL 메리트가 없다.
      • 도메인을 나누면 도메인 별로 DB를 관리하기 때문에 맞출 필요 없다.
        • 도메인이 따로 가는게 맞나?
          • 원칙적으로 따로 가는게 맞다고 생각한다.
      • 나중에 원하는걸로 갈아타자 → RDS
      • 학습의 목표는 DDD다. 덜어낼건 덜어내는걸로
      • DB를 쓰면 무결성을 유지해야되는데 따로 관리해야되는데 맞는가?
        • aggregate는 기본적으로 Entity 하나를 관리한다.
        • 각 Entity를 관리할 수 있는게 Interface다.
        • 주문이라는 도메인 안에서 데이터 무결성은 지켜야된다.
        • 주문 Bounded Context안에서만 있어야된다. 중복이 되면 안된다.
        • 오로지 주문의 주문으로서 주문임으로, 주문이 도메인 설계의 Essential 이다.
        • DDD에서 경계를 확실히 하는 것일관성을 유지하고 모아놓고 동작을 할 수 있는 게 DDD
        • 뭔가 다른게 섞여있으면 컨텍스트를 나누는 신호다.
        • 주문팀의 DB 스탠스는 따로 가는게 맞다로 의견 종합 내일 10월 6일 수요일날 종합 회의에서 백엔드 타팀이랑 논의!
      • 프레임웍
        • 스프링이냐 스브링부트냐
          • 빠른 개발을 위해 부트다. 부트다 부트.

  • CI/CD

    • 배포를 어디에 해야되는지 정하고 한다.
    • github action

  • 브랜치 전략

    • git flow vs github flow
      • github flow는 main branch 하나만 두고 함 → 머지하는 순간 바로 반영
      • git flow 는 dev branch → feat branch 따로 둬서 release 할 떄 마다 통합하는 것
    • 토이니까 리셋 하면 된다. 기간 6주라 버전 가져오는것도 힘들다.
    • github flow 관리하기 쉽다
    • fork vs orign repo
      • 어차피 차이 나는 건 없다.
      • fork다

  • 테스트코드 작성 방법

    • spring context를 띄우면 더욱 더 빠르게 돼는 반면, Mock 객체를 만드는것도 훈련 중 하나다. 학습 학습 → 통합테스트 | 테스트 데이터베이스를 따로 만든 것
    • 업무 진행을 했을 떄, Mock을 안사용하고 fakedb에 집적 심어놓고, db interface 콜 하듯 진행함.
    • Mock을 써서 각 Method 별로 인자를 받았을 때 어떤 값을 반환한다. 테스트 마다 설정함. → 기능이 바꼈을 때 Mock을 다 변경해야되는 불편함이 있음. 결과 포함 → 생산성 비용 업업
    • Method 하나하나 digest 할 때 힘듬 → 단위 테스트 → 통합 테스트
    • 코드숨에서는 Spring Context를 안쓰는 추세 → 종립님은 memory db에 하는 것을 선호한다.
    • 단위 테스트가 필요한 경우가 있지 않은가?
      • memorydb를 만드는게 아닌 method 별로 집적 함수를 만드는게 아니라 함수를 호출하면 요런저런 데이터를 만든다.
        • 해당 상단의 spring context를 띄우지 않았는가?
          • class로 객체를 만들어서 Inject를 주입시켰기 떄문에 안했다.
    • Spring을 걷어내면 좀 더 이해할수 있다.
    • 둘다 Trade-off 가 있다...
    • 정수님 개인 선호: Mock을 사용하지 아니함
      • 본인담당하는 코드에 대해서 test code를 작성하는 것에 취향 반영하자
      • 토이 vs 진짜 프로젝트냐
      • 본인이 하는대로 진행해보자 일단. 어떤 테스트 코드가 좋은지는 추후에 결정
      • 학습에 의의를 두자.

  • commit PR은 통일하자

    • code level - eng
    • else - kor

  • PR/ISSUE Template은 보류

    • 정성껏 남이 보면 이해하기 좋도록...
    • 깃 가이드라인 맞춰서 하고 잘 작성해보는게 좋다.
    • 나중에 다시 한번 논의

  • 이벤트 스토밍

    • 미로 링크
    • 외부 결제 시스템은 어렵다
    • 주문을 단순화 시키자
    • 복잡한 도메인이다
    • 이벤트 스토밍 때문에 이해가 뭔가 이해가 더 어려웠다. → 형식에 맞추다보니 좀 더 어려워졌다.
    • 이벤트 스토밍이 100% 정답은 아니다.
    • 객체를 도출 하는 행위

  • 바운디드 컨텍스트

    • To Be Discussed

  • API 명세

    • To Be Discussed

덕수: 머리가 아프지만, 같이 도메인 모델링하면서 도메인 발견해나가는 재미가있었다. 주완: 재현을 잘못했나? 생각했지만 참여해줘서 Thank you! aggregate추가해서 진행해봐야겠다. 주원: 6주 길 줄 알았는데... 짧은 거였다... 결제는 도메인을 따로 두는 전략이 좋겠다. 합리적인 스케줄을 짜자. 형탁: 이벤트 스토밍을 하는데 UI랑 연동 했던것같다. → 행위에 집중. 다음에 다시. 혜원: UI부분이랑 도메인 모델링이랑 혼합되서 혼동이옴. → 주완님 작성하신 베이스 떄문에 좋았다. 홍석: 프론트 코드로 접근하다가 → 모델 구현을 어떻게 하는지 혼란이 와서 어려웠었음. → 모델에대한 설계와 UI에 대한 설계를 나눠야되는지 궁금하다. flow 궁금 정수: 자러가겠습니다!