Adapter: Web, Messaging PR 작성 및 정리

오늘은 오전에 Web, Messaging 작업한 것에 대한 PR을 작성했다. 약 2주동안 정말 열심히 고민하고 만들었는데, 작업 내용을 정리하고 보니 그 고민과 노력만큼의 결과물이라고 하기엔 다소 많이 아쉬웠다. 역시 아직 경험이 너무 부족한 신입개발자의 티를 숨길 순 없나보다..

---

Feature/product adapter: Messaging, Web #5

 

오늘 드디어 오랜만에 PR 작성을 완료했다. 예상했던 기간보다도 오래걸렸고, 스스로 부족한 부분으로 인지한 부분도 많았던 개발 부분이었다.

 

Feature/product adapter: Messaging, Web by KEEMSY · Pull Request #5 · KEEMSY/shoes-ordering-system

 

이번에 새로 작성한 PR, 아직 리뷰는 없다..

이번 PR은 Messsaing 과 Web 이 합쳐 작성되었다. 각 두부분의 작업이 작을 것이라고 생각하여, 두개를 합쳐 작성했다. 그리고 실제로도 작업량을 본다면 그렇게 크지 않다.

 

---

Messaging

 

Adapter 의 out에 해당하는 messaging 은 이벤트 발행을 위한 Kafka 모듈의 개발이다.  이 부분에 대해서는 이전에 사용한 템플릿과 코드를 현 상황에 맞기 재사용했기에 정말 한두시간만에 모두 끝냈던 것 같다.

 

내가 Product 도메인에서 사용하는 이벤트에는 CreatedProductEvent 와 UpdateProductEvent 가 존재하며, 나는 이 2개의 이벤트를 추가하였다.

 

이전에는 단위테스트, 통합테스트만 작성했었는데, 이제는 각 계층에 대한 테스트도 작성하게되면서 생긴 고민이 하나 있다. 바로 어떻게 messaging 계층을 테스트해야하는가이다. messaging 계층에서의 테스트 어떻게할래? 라고 스스로 물으면, 정말 머리가 멍해지는 것같다..

 

---

WebController

 

웹 계층 뿐만아니라, 다른 모든 개발을 진행하면서, 각 객체의 책임에 대해 고민했고, 책임에 따라 개발을 진행했다. 웹 계층의 책임은, HTTP 요청을 자바객체로 매핑하고, 또 유스케이스의 응답 값을 HTTP 응답으로 반환하는 것이다. 그리고 해당 과정 진행 전, 입력 유효성을 검사해야한다.

 

이 부분은 사실 도메인 계층을 개발하면서 고민했던 부분이다. 그리고 그 당시의 설계는 오류가 있었다. 그러나 해당 오류는 Web 계층을 개발 할 때서야 인지할 수 있었다.

 

지난 웹 계층 테스트에 관한 TIL 포스팅의 일부분

그리고 이 부분을 확인하면서 나는 기존 개발 루틴에 수정이 필요함을 느꼈다. 아직 어떻게 개선해야겠다 생각이 뚜렸하지 않지만, 개선은 필요해 보인다.

 

나는 HTTP요청을 Command(수정) 과 Query(조회) 로 분류하였다. 해당 부분은 애플리케이션 계층을 개발할 때부터 반영된 부분으로, 웹 계층 또한 이를 반영하였다.

 

---

피드백(?)

 

너무 장황하다는 내 프로젝트..

나는 기술 중심의 개발이 아닌, 비즈니스 중심의 개발의 목표를 갖고있다. 그리고 이를 위해 클린아키텍처(헥사고날아키텍처, 포트앤어댑터)를 공부하고 있다. 또 이를 좀 더 효율적으로 공부하고자 실제 프로젝트로 만들어보고 있는 요즘이다.

 

그런데 프로젝트를 진행하면서 부정적인(?)이야기를 정말 많이 들었던 것같다. 나쁘진않은데, 지금 상황에서 왜 굳이?, 너무나 간단한데 너무 과한것아니야? 하는 이야기를 꽤 많이 들었던 것 같다.

 

사람마다 느끼고 받아들이는 것이 다르겠지만,   장황하다는 의견을 말했듯, 내 의견을 말하자면, 나는 이 피드백이 잘 와닿지가 않는다.

세분화된 아키텍처 구조가 장황한 것일까.. 장황함의 측정은 비즈니스의 성장도로 이뤄져야하지 않을까.. 하는 생각이다.

 

같은 크기의 작은 두 집 중, 잘 구조화되고 내부구조가 튼실한 집과 과 딱 집의 형태로서 필요한 것만 갖춘 집이 있다면? 전자의 집은 장황한 집이라 할 수 있을까? 나는 아니라고 생각한다.

 

아키텍처에는 늘어나는 사용자와 증가하는 데이터 처리에 대하여 효율적으로 처리할 수 있어야 함을 의미 하는 확장성이라는 특성이 존재한다.  그렇다면, 확장성을 갖춘 아키텍처는 장황하다 이야기할 수 있을까? 이에 대한 답은 시스템이 어떻게 확장성을 보장하느냐 를 공부하면 알 수 있다. 그리고 나는 이 답을 현재는 아니다.라고 생각한다.

 

하지만 나도 지금의 아키텍처에 관해서 고민이 없다는 것은 아니다. 계속해서 아키텍처에 대한 질문과 아키텍처에 대한 부정적인 피드백 때문이다. 하지만 이러한 피드백 사항들은 해당 아키텍처를 처음보는 사람들이라면 당연하게 생각하는 부분이라고 생각하고.. 다양한 사람들과 이야기를 나눠보고싶다.. ㅠㅠ

 

---

나는 개발을 공부하고 또 일을 하면서 생긴 원인모를 불편함과 고민을 클린아키텍처와 DDD를 공부하는 것으로써 해결할 수 있을 것 이라고 생각했고, 공부하고있다. 실제로 관련된 책을 공부하면서, 내가 이것때문에 불편했구나, 불편할 수 밖에 없었구나 하는 생각을 할 수 있었다. 따라서 나는 해당 내용에 대하여 공부하는것이 필요하다 생각한다.

 

하지만 최근의 유튜브영상, 그리고 이러한 피드백들.. 내가 과한것일까..? 평소와는 다른 고민을 하게 되는 것 같다... 그래도 즐겁다. 이런 고민으로 더 나은 방법을 찾게 될 테니깐!

 

지금의 고민들과 피드백 사항들을 잘 기록하고 정리해서 기회가 될 때, 다른 사람들과 이야기를 해봐야겠다.

 

그리고 이제 Product 문서정리가 거의 끝났고, 지금 리뷰가 끝이나면, Product 브랜치를 main에 병합하고 드디어 Order를 시작한다. 그간 피드백 사항을 잊지않고 잘 반영해서 더 좋은 Order 도메인을 개발할 수 있도록 하자!! 할 수 있다 !!!!