항해 플러스 - 3주차 WIL

발행일 2025년 4월 11일  •  2 분 소요  • 338 단어

1. 내가 선택한 시나리오와 도메인 모델링 방향

2주차에서 5주차까지 구현해야 할 프로젝트로 E-커머스 서비스를 골랐고, 저번 주 설계에 이어 이번 주에는 본격적인 구현에 들어갔다.
도메인 객체를 크게 Customer, Balance, Product, Coupon, Order, Payment로 나누었고, 이것들과 연관된 하위 도메인 객체의 개념까지 합해서 총 12개의 객체를 나름대로 디자인하고 활용했다.
사실 도메인 객체를 객체지향적이기 보다는 DB 테이블 연관관계를 기준으로 나눈 것 같아서 썩 흡족한 도메인 설계는 아니었다.
DB 다이어그램과는 또다른 객체지향적 도메인 설계에 대해서는 추가적인 공부가 필요하겠다.

2. 클린 아키텍처 설계를 하며 어려웠던 점과 그 이유

일반적인 Controller → Service → Repository 구조를 개발할 때는 크게 헷갈릴 만한 부분이 없었다.
하지만 외부 데이터 플랫폼으로 주문 정보를 전송하는 로직이나, 스케쥴러를 통해 쿠폰 만료 처리를 하는 로직은 어떤 계층에 어떤 클래스를 두어야 할지 헷갈렸다.
Application 계층에서 하위 계층의 로직들을 조합해 활용하는 방식이 맞다고 생각하여 그렇게 개발했다.
클린 아키텍처와 도메인의 개념에 대해 더 공부하면서, 이것이 옳게 된 설계인지 한 번 더 고민해보는 시간을 가져야겠다.

3. 비즈니스 로직 구현에서 고려한 설계 포인트

Domain 계층에서의 핵심 비즈니스 로직들과, 그것들을 조합하는 Facade의 역할에 집중하며 개발을 진행했다.
솔직히 아직 많이 미흡하다고는 생각하지만, 최대한 객체지향적인 관점에서 클래스가 있어야 할 계층에 대해서 많은 고민을 해봤다.
앞으로는 다른 프로젝트들을 살펴볼 때에도 설계 관점에서 어떤 방식이 클린 아키텍처에 걸맞는 방식인지 살펴보는 버릇을 들여야겠다.

4. 단위 테스트를 설계하며 배운 점

이번 과제는 Repository에 대한 실제 구현체가 없었기 때문에 테스트에 대한 의존도가 극도로 높아졌다.
사실 기존에는 개발을 해오면서 기능을 개발하면 거의 무조건 서버를 실행하고 직접 API를 콜해보면서 내 기능이 맞게 구현된 것인지 확인해 왔었다.
하지만 이번에는 실제 구현체가 없으므로 테스트 코드에 대한 믿음만으로 밀고 나가게 되었다.
이런 상황이 되다보니 단위 테스트의 역할과 중요성에 대해 확실히 체감이 많이 되었다.
모든 케이스에 대해 정교하게 잘 작성된 테스트 코드를 작성하는 역량을 길러야겠다는 필요성을 느낄 수 있었다.

5. 이번 과제를 통해 느낀 ‘아키텍처 설계의 가치’

기존에 일반적이고 기본적인 MVC 패턴만을 답습해왔을 때에는 잘 생각해보지도 않던 ‘객체지향 설계’에 대한 고민을 많이 해보게 되었다.
이번에 Clean + Layered Architecture를 공부하며 적용해보니 확실히 아키텍처 설계의 필요성에 대해 절감하게 되었다.
목적에 맞게 명확히 정의된 계층들과, 각자의 책임과 역할에 맞게 정교하게 구분된 클래스들.
이것들과 함께라면 유지보수성이 높은 코드를 작성할 수 있으리라는 믿음이 생겼다.