SA 문서 작성
API 명세서 리뷰
API 명세서를 한명씩 발표하며 전체적으로 피드백을 전달했다. 발표 과정에서 요구사항 중 애매했던 부분을 정리하고, 같은 개념을 일관성 있게 통일할 수 있었다. 또한, 빠뜨린 부분도 확인할 수 있었다. 추가로 UUID 대신 더 효율적인 TSID를 키 타입으로 사용하기로 결정됐다. 그리고 데이터가 추가되거나 변경, 삭제될 때는 변경된 시간을 응답에 포함하기로 합의했다.
ERD 작성 및 테이블 명세서
원래는 테이블 명세서를 먼저 작성해야 한다고 배웠지만, 더 빠르게 진행하기 위해 설계한 API를 바탕으로 ERD에 데이터를 작성했다. 이후 테이블 명세서를 작성했는데, ERD를 먼저 완성해둔 덕분에 작업이 수월했다. 하지만 간단하게 데이터 자체로서 요구사항과 함께 고민을 더 해볼 수 있었고, 테이블 명세서를 먼저 작성하라고 제시해주신 이유를 체감했다.
DDD 특강
개념과 핵심 가치
소프트웨어를 설계할 때 고객의 요구사항을 명확히 이해하는 것이 중요하다. 이를 위해 도메인 지식이 설계의 중심이 되어야 한다는 점을 강조했다. 도메인 전문가와 개발자가 협력해 도메인 모델을 구축하고, 유비쿼터스 언어를 사용해 설계의 모든 과정에서 같은 언어를 사용하는 것이 핵심이라는 점을 배웠다. 이런 방식은 설계의 일관성을 유지하고, 오해를 줄이는 데 큰 도움이 된다.
도메인 모델과 구조
도메인 모델은 복잡한 비즈니스 개념과 규칙을 추상화한 것이다. 엔티티와 벨류 객체 같은 기본 구성 요소를 포함하며, 애그리거트를 통해 관련된 객체들을 하나의 단위로 묶어 관리한다. 특히, 도메인 서비스는 여러 엔티티에 걸친 규칙을 처리하는 데 중요한 역할을 한다.
4계층 구조와 레포지토리 패턴
DDD에서는 표현, 응용, 도메인, 인프라스트럭처로 이루어진 4계층 구조를 기반으로 설계를 진행한다. 레포지토리 패턴은 도메인 모델의 변경을 레포지토리를 통해서만 가능하게 한다. 이를 통해 데이터 접근과 비즈니스 로직을 분리해 유지보수를 쉽게 할 수 있다는 점이 인상적이었다.
MSA에서의 적용
MSA로 전환하는 과정에서도 DDD는 유용하게 활용된다. 특히, 서비스의 식별과 설계에 체계적인 방법을 제공해 준다는 점에서 MSA와의 조화가 잘 맞는다고 느꼈다.
자주 묻는 질문
- JpaRepository는 DB와 관련이 있기 때문에 인프라스트럭처 영역에 해당한다. 필요하면 도메인 레포지토리와 협력하도록 설계할 수 있다.
- JPA 엔티티와 DDD 엔티티는 유사하지만, 용도와 컨텍스트에 따라 약간의 차이가 있다.
- 루트 애그리거트를 지나치게 제한하면 성능 문제가 발생할 수 있다. 이런 경우, 하위 엔티티를 조회 전용 레포지토리로 관리하는 방식이 권장된다.
- 도메인 서비스는 비즈니스 규칙 자체를 다루는 반면, 애플리케이션 서비스는 트랜잭션이나 외부 API 호출 같은 흐름을 조율한다.
튜터님 QnA 요약
요구사항과 가이드의 상충
Q1. 필수 요구사항과 요구사항 가이드가 일부 상충되는 부분이 있었는데, 표기된 항목이나 값은 가이드를 위한 참고 자료로 이해하고 작업을 진행하는 것이 좋을까요?
A1. 맞습니다.
백업 정보 보관 기간
Q2. 개인 정보 아닌 백업용 정보는 어느정도의 보관 기간이 적당할까요?
A2. 백업 정보는 활용 방식에 따라 보관 기간이 달라집니다. 데이터의 성격에 따라 주기는 천차만별입니다.
CRUD + Search 구조
Q3. 모든 도메인에서 CRUD + Search를 기본적으로 생각하라는 요구사항이 있었는데, AI 응답이나 메시지 도메인같은 경우 수정이나 삭제가 있는 것이 이상하다고 생각됩니다.
A4. 꼭 고정적으로 적용할 필요는 없습니다. 이를 생략하고 적합한 구조로 설계하는 것이 좋을 것 같습니다.
테이블명 단수형 vs 복수형
Q4. 컨벤션의 경우 정하기 나름이라고 하지만, 보통 관례적으로 더 많이 사용되는 쪽이 있다고 생각합니다. DB 테이블 이름은 단수형과 복수형 중에 어떤 것을 선택하는 것이 좋을까요? A4. DB 테이블 이름은 단수형을 사용하는 것이 일반적입니다. 단수형은 명확하고 직관적이기 때문에 더 보편적으로 사용됩니다.
Git
컨벤션 설정
팀원들과 논의하여 Git Branch, Commit Message, Issue Label, PR Template 등 주요 컨벤션을 결정했다. 대부분 의견이 비슷해서 쉽게 결정될 수 있었다.
GitHub 레포지토리 생성
Organizations를 생성하고 팀원들을 초대한 뒤, 권한을 설정했다. 기존에 Issues에서 시작해 작업했던 방식에 Projects를 추가로 사용해보기로 했다. Projects를 통해 작업을 계획하고, 이후 Issues를 생성해 구체적인 작업을 진행하는 방식이다.
- Projects에서 작업 계획 작성
- Issues 생성 및 작업 세분화
- Commit과 Push로 진행 상황 저장
- PR을 생성하고 코드 리뷰 요청
- 리뷰 후 승인되면 병합
- 브랜치를 삭제하고 Issues를 닫아 작업 종료