Tech Diary Tech Diary

이커머스 설계 과제를 하면서 배운 것들 — "요구사항 정리"가 이렇게 어려운 거였나?이커머스 서비스의 설계 문서를 작성하면서 배운 것들을 정리합니다.요구사항 분석, 시퀀스 다이어그램, 클래스 다이어그램, ERD — 각 단계에서 어떤 함정이 있었고, 어떤 기준을 세웠는지이번 주에 한 것감성 이커머스 서비스의 설계 문서를 작성했다. 브랜드, 상품, 좋아요, 주문. 도메인 자체는 흔하다. 좋아요 누르고, 여러 상품을 한 번에 담아 주문하는 서비스. 대고객 API(/api/v1)와 어드민 API(/api-admin/v1)가 분리되어 있고, 주문 시 상품 스냅샷 저장과 재고 차감이 핵심 요구사항이다. "이 정도면 금방 끝나겠지"라고 생각했다. 전혀 아니었다.1. 요구사항 정리는 API 명세의 한글 번역이 아니다처..

TDD를 실제로 직접 구현회원 API를 TDD로 만들어야 했다. Red → Green → Refactor. 개념은 알고 있었다. 그런데 막상 빈 프로젝트를 열고 나니 손이 멈췄다.DTO도 없고, 도메인 모델도 없고, Repository 인터페이스도 없다. 테스트를 먼저 작성하라는데, 대체 뭘 테스트하라는 건지 감이 안 왔다. 이번 주는 그 막막함에서 시작해서, 테스트 더블이라는 개념을 처음 배우고, 멘토링에서 실무 기준을 잡기까지의 기록이다.1. 테스트 더블회사에서 테스트를 작성할 때 mock()을 쓰고 verify()를 쓰긴 했다. 그런데 그게 "Mock"인지 "Stub"인지 구분해서 쓴 적은 없었다. 이번 주 발제에서 테스트 더블이라는 개념을 제대로 배웠다.역할목적핵심Dummy자리만 채움 (사용되지 ..