WIL - 3주차 (Domain Modeling)

이번 주차에는 지난주에 설계한 내용을 바탕으로 실제 코드를 구현해보았다.
아직 DDD와 클린 아키텍처가 익숙하지 않다 보니 전체적인 구조를 잡는 데에 꽤 많은 시간이 소요되었고, 각 계층의 역할을 구분하여 구현하는 것이 쉽지 않았다.

이번 구현은 다음과 같은 순서로 진행하려고 노력했다:

도메인 테스트 코드 작성 → 엔티티 생성 → 서비스 테스트 코드 작성 → 서비스 구현 → 파사드 테스트 코드 작성 → 파사드 구현

 

정확하게 맞는 방식인지는 잘 모르겠지만, 도메인 엔티티를 우선 정의하고, 해당 도메인에서 수행되어야 하는 기능들을 도메인 서비스에 작성하는 방식으로 접근했다.

📦 도메인 서비스 구성

• BrandService
  브랜드 생성, 브랜드 단건 조회
• ProductService
  상품 생성, 상품 조회, 재고 차감/추가 등 재고 관리 기능
• LikeService
  좋아요 등록 및 취소, 유저의 좋아요 목록 조회, 상품별 좋아요 수 조회
• PointService
  포인트 조회, 포인트 충전, 포인트 차감
• OrderService
  주문 생성, 유저의 주문 목록 및 주문 상세 조회

🧩 파사드 계층 구성

도메인 간 조합이 필요한 유스케이스는 파사드(Facade)에 정의하였다.

• ProductFacade
  • 브랜드 정보와 좋아요 수를 포함한 상품 단건 조회
  • 정렬 조건(최근순, 좋아요순, 가격순)에 따른 상품 목록 조회
• LikeFacade
  • 유저가 좋아요한 상품 목록 조회
• OrderFacade
  • 주문 생성 (상품 재고 차감 + 포인트 사용 포함)

그리고 계층 별 DTO를 사용해야 한다는 것을 새로 알았다.

📄 계층별 DTO 구조 이해

이번 주차에 새롭게 배운 점 중 하나는, 계층별로 DTO를 구분해서 사용하는 것이 중요하다는 점이었다.
처음에는 DTO 하나로 다 써도 되지 않나 싶었지만 각 계층의 역할과 관심사가 다르기 때문에 입력과 출력 모델도 다르게 관리해야 함을 배웠다.

 

계층	Input	Output	설명
Interface(API)	Request	Response	HTTP 요청/응답 포맷. 유효성 검증 및 Swagger 문서화 대상
Application	Criteria	Result	유스케이스 수행에 필요한 조건 정의, 결과 데이터 포맷
Domain	Command	Info	비즈니스 로직의 입력과 출력. 검증 및 상태 변경 중심
Infrastructure	Params	Entity / VO	DB 질의를 위한 파라미터, 실제 엔티티 또는 서브 도메인 반환

 

아직은 이러한 구조와 규칙이 익숙하지 않아서 코드를 작성하는 데 시간이 오래 걸리는 것 같다.
그래도 각 계층의 책임을 분리하는 구조의 필요성과 장점을 조금씩 체감하고 있다.
자연스럽게 구조를 설계하고 구현할 수 있도록 연습 많이 해야지 ...