ApplicationService(유스케이스) 구현과 고민

오늘도 고민은 계속됬다. 요즘에는 매일이 개발의 연속이 아닌, 개발 고민의 연속인 것 같다. Member 도메인의 개발을 마치면, 이 후의 도메인들은 개발이 금방금방 될 것이라 생각했었는데, 잘못된 생각이었다. 역시 공부하면 할 수록, 이전의 나를 되돌아보게하면서 쉽게쉽게가아닌 고민을 하게한다. 그리고 이러면서 조금씩 성장해나가는 것 같다.

---

ApplicationService 구현

 

출력모델(Out Model, CreateProductResponse)

 

나는 어제 CreateProductCommand(DTO이자 클린아키텍처에서 Input Model) 를 개발했다. Input Model 에서 입력 유효성을 검증하는 방법을 고민하고 적용하는데 공부의 대부분의 시간을 소모했고, 어제 이 문제(고민)을 해결했으니, 다음 Out Model(CreateProductResponse)는 손쉽게 개발할 수 있을 것이라고 생각했다. 하지만 역시나 그렇듯 그렇지 못했다.

 

유스케이스가 할 일을 다하고 나면 무엇을 반환해야할까? 에 대한 고민은 지난 Member 도메인을 개발하면서 잠깐 했었다. 당시에는 생성의 경우, 그냥 누가 생성됬다라고만하면되는것 아니야? 하는 생각이었다.

 

CreateMemberResponse에서는 누가(memberId), 어떤 상태(memberStatus)의 Member 를 만들었고, 특이사항(message)가 있었는지를 반환했다.

 

당시에는 이것이 그냥 물흐르듯 당연하게 이 정보들이 필요하겠는데? 하는 생각에서 이렇게 개발했다. 그런데 지금 돌이켜보니, 저것들이 다 필요한 정보들일까? 정보가 부족한 것은 아닐까? 하는 생각이들었다. 그리고 Product 생성시에는 어떤 데이터가 필요할까? 하는 고민에 빠졌다. 책에서는 이 질문에 정답은 없지만, 유스케이스를 가능한 구체적으로 유지하기 위해서는 계속 질문해야하며, 의심스럽다면 가능한 적게 반환하는 것을 추천했다.

 

나는 CreateProductResponse 에서 생성한 Product의 모든 정보를 반환하도록 하였다. 그런데 나는 이것이 최선일까..하는 의심이 든다. 최소의 정보만 반환한다면 어떤 정보를 반환해야 할까? 고민 끝에 나는 기존의 설계와 같이 생성한 Product 를 반환하도록 하였다. 이전의 CreateMemberResponse 처럼 축약을 해볼까? 하는 생각이 들었지만, 지금 생각에서는 CreateMemberResponse의 정보가 부족한 것 같다는 생각이 들었다.(지금이 딱 적당한 응답인것 같다.)

 

그런데 진짜 고민은 Track(Query)에 대한 부분이다. TrackMemberQuery 는 하나의 Member 만을 조회했다. 하지만 이번 Product 에서는 단일, 다수의 Product 를 조회해야한다. 이에 대하여 지금 드는 생각으로는 조회 유스케이스가 세분화가 또다시 이뤄져야할 것같다는 생각이 들었다. 근데 이렇게 계속해서 세분화하는 것이 맞을까? 고민이된다.. 책을 읽으면서 지금까지 드는 생각으로는, 큰 덩어리보다는 작은 조각들이 훨씬 더 좋다는 견해를 봐왔기에, Track 개발 시, 세분화를 하여 Out Model을 생성하려고한다.(물론 언제나 그렇듯 개발할 때면 바뀔 수 있다.)

 

---

(Member)Helper에 관하여, 트레이드 오프

 

나는 ApplicationService에서 각 유스케이스를 CommandHandler 를 통해 분리하였다. 그리고 각 CommandHandler에서는 영속성 계층(DB)에 접근하여, 도메인의 상태를 저장하거나 변경한다. 여기서 각 CommandHandler에서는 영속성 계층에 대한 중복되는 코드가 발생한다.

 

나는 영속성계층에 사용되는 중복되는 코드(Repository, DomainService)의 중복을 줄이고 재사용성을 높여줄 수 있는 모듈 Helper 를 만들었다. 그런데 공부를 하다보니, 이 Helper 클래스가 잘못된 클래스가 아닌가? 하는 생각이 들었다. Helper(공유모델)은 장기적으로 보았을 떄, 시간이 지나면 지날수록(고도화가 될수록) 점점 커지게 될 것이다. 이에 대하여, 이 선택이 맞는 선택일까? 하는 고민을 하게 되었다.

 

공유 모듈을 만들 시, 얻을 수 있는 가장 큰 장점은 재사용성을 이야기 할 수 있을 것이고, 우려되는 문제점으로는 커플링을 이야기할 수 있을 것 같다. 재사용을 통한 코드의 중복을 줄일 수 있다는 것이 너무 매력적이다. 뿐만아니라 만약 Repository, DomainService 를 수정하는 일이 발생할 경우 한 곳(Helper) 에서만 수정하면 된다는 것이 유지보수성 측면에서 큰 이점이라고 생각이 된다. 하지만, 커플링이라는 것이 너무 맘에 걸리고.. 공유는 정말 양날의 검이다!! 일단은 내가 생각하기에, 장점(2개)이 단점(1개)보다 많으니깐 Helper를 사용해야겠다.

 

이것에 대해서도 기회가 된다면, 여렇 사람들과 이야기를 해보고 싶다.