적절하게 ddd 를 도입하기 위한 생각 (백엔드 관점)

지금까지 ddd 를 진행하면서, 이런 방식으로 진행하면 어떨까 하는 생각들입니다

• 가장 먼저 시제품 PoC 하기! DDD를 쓰지 않기! (2주안에)

  • ddd 를 초기에 사용하지 않는다

    • 오직 mvp 를 개발한다, 불필요한 추상화는 최대한 피한다

    • 대신 리빌딩을 염두하여, 프로젝트 파일 구조나 use case diagram 등 유연한 설계 기법을 찾아본다

  • 이유:

    • 기능 개발에 있어서, 경험이 풍부하다면 ddd 를 바로 해도 괜찮겠지만,
      팀 전체를 고려하면 기술과 도메인을 한번 빠르게 구현해보는게 낫지 않을까

    • 도메인 전문가와 협업하기 이전까지는 가장 '빠르고' 적절한 개발 원칙을 결정한다

  • 프론트엔드와 협업하며, 필요한 api 의 문서를 작성한다

    • 핵심 기능을 완성해야한다

  • 최대한 기능 단위로 개발한다

    • 완성 후, 대략적인 document 문서를 공유한다

• 이후, 도메인 전문가 및 이해관계자와 이벤트 스토밍 워크샵을 진행한다

  • 도메인 전문가는 이벤트와 ReadModel 포스트잇에 집중한다

  • 이해관계자는 이벤트 포스트잇에 집중한다

  • 개발자는 진행을 주도하며, 모든 포스트잇을 분석한다

    • 모순을 찾아 설명하고, 수정한다

    • 없는 부분을 찾아 설명하고 추가한다

• 이미 개발되어있는 코드와, 기획/이벤트스토밍에 있는 용어를 사전으로 만든다

  • 기술과 도메인의 중요도, 인프라 DR 등을 고려하여 Bounded Context 를 만든다

  • 각 BC 문서마다 유비쿼터스 언어를 정의하는 용어사전을 만든다

• ddd 로 전환하기

  • anti-corruption / strangler 패턴을 쓰지 않고 빠르게 새로운 mock api 를 추가한다(이벤트 스토밍 기반)

• 설계하기

  • ddd 를 떠나 팀의 역량에 맞는 디자인 패턴 및 베이스라인(코드 스타일, 컨벤션)을 설계한다

    • 이때 이미 작성되어 있는 코드를 고려한다

    • 앞으로 구현할때 고민할 수 있는 사항들을 빠르게 탐색하여, 구현시 고민하지 않도록 시간을 쏟는다

    • 개발팀은 각종 정보를 토대로 초급 개발자가 개발할 수 있을정도로 디테일한 부분까지 설계해야한다

• 구현하기

  • 이후 각 영역의 업무를 최대한 작은 단위로 나누고, 이를 팀원에게 할당하여 진행한다

• 투명하게 전달(통합)하기

  • 프론트엔드에게 api document 를 공유하고, 피드백을 api 문서에 반영한다

  • api docs 에 대한 질문들과 답변을 api docs 문서에 기록한다

• 개선점 고려하기

  • 유닛 테스트는 구현하면서 만들어도 괜찮다

  • e2e 테스트는 웬만하면 api 문서 공유와 함께 검증될 것

    • 성공 사례 위주로 작성한다

    • 실패에 대해서는 QA팀과 함께 진행한다

      • 이벤트 스토밍 워크샵에서 QA 는 실패 가능한 사례를 리스트로 작성해두면 좋다.

      • 이 내용또한 공유되면 개발사항이 투명해진다

이해관계자 예상 인원

• 프로젝트 오너

• 도메인 전문가

• QA(품질 관리자)

• CX(고객 경험 관리자)

• 디자이너

• 프론트엔드 개발자

• 백엔드 개발자 3명(시니어 1, 주니어 2)

예상 일정 산정

• MVP POC 개발 및 프론트엔드 전달(시스템 분석 포함):

  • 3주 이내

• 이해관계자(프로젝트 관련자) 대상 시연:

  • 1일

• 이벤트 스토밍 워크샵:

  • 3일

• ddd 기반 시스템 분석:

  • 2주

• 베이스 라인(컨벤션 및 디자인 패턴 등) 설계 작성 및 e2e 테스트 작성

  • 2주

• 개발

  • 2주

• 이해관계자 대상 시연:

  • 1일

  • 피드백 및 이후 일정 산정