Order 도메인 계층 완료, 재밌는 독서

오늘은 오전에 늦잠을 자고, 책을보다 운동을 늦었다. 디자인 패턴 책을 공부하면서, 좋은코드 나쁜코드 책을 함께보는데 디자인 패턴은 복습이면서, 적용될 케이스를 상상하다보니 계획한 것보다 더 많은 시간을 소요하게되고, 좋은코드 나쁜코드 책은 오늘 읽은 부분이 내가 관심이 많은 가독성 코드 관련된 부분 에 대한 이야기여서 그런지, 시간가는줄 모르게 책을 봤던 것 같다.

 

운동은 다음주 월,화 헬스장이 휴관이라서 조금 욕심을 내서 평소보다 오랫동안 하고 왔다. 그래서 개발을 하는 시간이 훨씬 더 많이 늦어졌다. 하지만 후회는 없다. 후회없이 운동도하고, 재미나게 책도보고 그리고 오늘 목표한 개발도 다 했기 때문이다~!

 

---

Order 도메인 계층 개발

 

어제 하던, Order 도메인 계층 개발은 다하고나니 별거 없지만(?) 이 코드를 작성하는데 정말 많은 고민과 시간이 들었다. 역시 간단하고 쉬워보이는 일은 그 일이 정말로 쉬워서가 아니라 그 일을 하는 사람이 정말 잘하는 거였다는 것을 다시금 깨닫게 되는 것 같다.

 

나는 실제 경험한 주문을 기반으로 Order 도메인을 설계했다.하지만 100% 완벽 매핑되는 Order 는 아니다. 처음에는 이를 목표로(무모했다..) 설계를 했었는데, 많이 쉽지 않았다. 생각을 하면 할 수록 코드를 작성하기보다는 설계에 엄청난 시간을 소모하게되었다. 마우스를 잡기보다는 펜을 잡는 시간이 더 많았으니 말이다.

 

그래서 결국 타협점(?)으로, 공부 했었던 자료를 많이 참고했다. 내 상황에 맞춰 필요 없는 부분은 버리고 필요한 부분을 사용했다.

 

Order 도메인 계층내 AggregateRoot 인 Order 도메인 개발 간 작성한 Test

 

Order 엔터티에 필요한 도메인 로직을 생각하는 것이 정말 어려웠다. 간단하게 생각하면 간단(?)하지만, 간단하게 생각하는 것이 어려웠다. 내 벤치마킹은 나이키 주문이었는데, 최대한 이를반영한 개발을 하고자 하였다.

 

내 나이키 주문 경험은 다음과 같다.

 

1. 신발을 선택하고, 신발의 재고를 확인한다. 2. 재고가 존재한다면 주문이 가능하다. 3. 주문이 진행되기 위해서는 주문정보, 결제정보와 같은 특정 정보가 필요하고, 필요한 정보가 충족되면, 주문이 완료된다.

 

여기서 중요한 것은 3. 주문이 완료된다는 것이 결제가되는 것(주문완료)이 아니다. 2. 를 기점으로 재고가 존재했지만, 주문완료 시점 때까지 재고가 존재한다 보장할 수 없다.

 

그래서 주문을 완료하고, 주문 생성 이벤트를 발행 -> 해당 이벤트를 구독하는 다른서비스(재고를 담당하는 서비스?)에서 너가 주문할 땐, 재고가 있어 주문가능 -> 다른 서비스에서의 승인이벤트 발행 -> 해당 이벤트를 Order 도메인이 구독, 소비하면서 Payment 요청 이벤트 발행 -> Payment 도메인이 이를 구독, 소비하면서 Paid 이벤트 발행 -> 주문 승인(완료) 를 상상하며 설계했다.

 

이렇게 글로 적으니 가독성이 많이 떨어지는 것 같다.. 다이어그램으로 내 그림을 그려보아야겠다.

 

 

해당 도메인 로직을 가진 OrderDomainService

 

이런 도메인 로직을 가진 도메인 처리를 캡슐화한 OrderDomainService는 생각보다 많이 간단하다. 역시 캡슐화는 정말 대단한 것 같다. 개인적으로는 복잡한 이 주문 도메인처리를 생성, 결제, 승인, 취소 로 정리가 된다니.. 정말 좋은 것 같다. 그런데 OrderDomainService 를 테스트 및 개발하면서 고민이 되는 부분이 생겼다.

 

OrderDomainService 는 Order 클래스를 알아야할까?(Mocking 을 해야하는건가?) 하는 생각이 들었다. 나는 Order 를 개발할 때, 테스트를 작성하면서 Order를 개발했고, Order 클래스를 검증했다. 그런데 이 Order 객체를 사용하는 클래스에서 Order를 정상 Order로 생성하고, 세부 구현(public 메서드)을 알아야할까? public 메서드는 세부 구현사항으로 생각하지 않는건가?

 

이에 대한 내 생각은 public은  이름에서 public 인만큼 세부사항으로 바라보지 않는 것이 맞는 것 같다. 인터페이스 처럼 생각하는 것이 맞는 것 같다. 그런데 Order 객체를 정상적으로 다 만들 필요는 없는 것 같다. Order 객체의 public 메서드를 Stub 하여 Order 객체를 사용하는 클래스를 테스트를 하는것이 효율적인 것 같다. 하지만 일단은 Order 객체를 다 정상적으로 만들었다 ^^.... 관련해서 나중에 피드백을 받을 수 있다면, 혹은 이야기를 나눠볼 수 있다면 잊지말고 특정 클래스를 사용하는 클래스의 테스트에 대하여 이야기 해봐야겠다.

 

---

 

내일은 전체적인 내가 상상한 그림을 시각자료로 만들고, Order Domain 계층 PR을 작성하고선 Application 계층을 개발해야겠다. 그리고 생각보다 빨리 작업이 끝난다면, Adapter 도 개발해봐야겠다.

 

내일은 헬스장도 쉬는 날이니, 책과 개발에 좀 더 집중하자!