Order 도메인 계층 병합, 디자인 패턴 공부, 온라인 피드백

오늘은 책을 마음껏 보았는데 개발은 얼마 하지 못했다. 원래의 계획은 책을 보고 나서 PR을 작성하고, 셀프 리뷰를 진행하고 바로 병합한 뒤 애플리케이션 계층을 개발하는 것이었는데, 승원이의 연락이 와서 승원이와 온라인으로 3시간동안 개발관련된 이야기를 하다보니 원래의 계획이 많이 틀어졌다.. 그래도 후회는 없다. 승원이도 오랜만에 보고, 그동안 못했던 개발관련된 이야기도 함께하고, 재밌었다.

 

---

Order 도메인 계층 병합

Feature/order domain by KEEMSY · Pull Request #12 · KEEMSY/shoes-ordering-system

 

작성한 PR

오늘은 Order 도메인 계층을 Order 브랜치에 병합했다. 병합하기 앞서, PR 작성에 관하여 이전과는 다른 PR 을 작성하고자 하였다.

과거작성한 PR들을 보면, 해당 작업내용에 대한 부분이 많이 적었던 것같다는 생각이 들었기 때문이다.

 

과거 작성했던 Product 도메인의 Message, web 계층 개발 건

과거 작성했던 PR을 다시보면, 이것은 읽는 사람기준으로 작성된 PR이 아니라 작성자 기준으로 작성된 PR 이었다. 어떤 작업을 했는지 설명이 많이 부족하다.

 

그래서 나는 이 부분을 개선해보고자 PR 템플릿을 개선했다. 내가 가장 신경쓴 부분은 어떤 작업을 왜 했는지 설명하는 것이었다.

하지만 아직 여전히 이 PR이 부족한 것 같다. 아직 여전히 PR의 단위가 너무 크다.. 더 작은 PR로 작성할 수 있도록 노력해야겠다... 이와 관련해서 오늘 승원이와 이야기하면서 피드백을 다시 받았는데, Entity 를 개발했다면 해당 Entity 를 PR로 작성하여 작게작게 세분화하는 방법을 추천해주었다. 다른 실무에서는 어떻게 하는지 모르지만, 리뷰어의 입장을 고려한다면, 해당 방법도 충분히 적용해볼만 한것같다.

 

 

---

디자인 패턴 공부: Template Method - 하위클래스에서 구체적으로 처리한다.

 

오늘은 디자인 패턴 공부를 템플릿 메서드패턴, 팩토리 메서드 패턴, 싱글턴 패턴을 공부했다. 이들 중 오늘 가장 깊은(?) 생각을 하게 해준 템플릿 메서드 패턴에 대해 내 생각을 기록해보려고 한다.

 

 

---

Template Method

 

템플릿 메서드 패턴의 클래스 다이어 그램

 

템플릿 메서드 패턴은 아마도 공부하지 않더라도 많은 개발자들이 이 패턴인지 모른 채 사용했을 것 같다.(내가 그랬다.)  템플릿 메서드 패턴이란, 상위 클래스에서 처리의 뼈대를 결정하고 하위 클래스에서 그 구체적인 내용을 결정하는 패턴을 말한다.

 

가만보면, 클린코드에서의 내용이 떠오른다. 구현체에 의존해서는 안된다. 상위 클래스형 변수에 하위클래스의 인스턴스 중 어느 것을 대입해도 제대로 동작할 수 있어야한다.(LSP, 리스코프치환원칙) 등등 공부했던 수 많은(?) 내용들과 개발했던, 개발된 코드들이 떠올랐다. 그리고 나는 이 내용들을 공부하면서 자연스럽게 템플릿 메서드 패턴을 습득했는지 모른다.

 

 

---

템플릿 메서드 패턴을 사용하는 이유

 

템플릿 메서드 패턴을 사용하는 이유는 무엇일까? 1. 로직을 공통화 할 수 있다. 즉, 상위 클래스의 템플릿 메서드에 알고리즘(처리흐름)이 기술되며, 일일히 하위 클래스 쪽에 작업 알고리즘을 작성할 필요가 사라진다.

 

아마도 인터페이스 혹은 추상클래스를 사용하여 개발하는 개발자라면 분명 하위클래스의 메서드를 상위 클래스로 올려본 경험이 있을 것이다. 그리고 하위클래스에서 상위클래스로 올라간 메서드는 다른 구현체(하위클래스)에서 같은 처리 흐름을 갖게되는 메서드였을 것이다.(내가그랬다.) 그리고 그것이 바로 템플릿 메서드 였던 것이다!

 

2 하위클래스를 상위 클래스와 동일시 할 수 있다.(LSP) 즉, 템플릿 메서드 패턴을 사용하면 구현체에 의존하지 않을 수 있다. 템플릿 메서드를 통해 수 많은 하위 클래스에서 구현을 다르게하여도, 처리의 큰흐름은 동일하기에 상위 클래스에서 구성한 목표를 이룰 수 있다. 즉, 다형성을 보장할 수 있게 된다. 그리고 나는 이것이 템플릿 메서드를 사용하는 가장 큰 이유라고 생각한다.

 

이렇게 공부하다보면, 나도모르게 사용하던 패턴들을 알게 되는 것이 정말 재밌다. 패턴이라함은 어렵고, 내가 하는 작업에 적용하는 것이 정말 어렵다고 생각이 먼저 들게되는데 그렇지 않다. 패턴도 별거없다!  

 

 

---

온라인 피드백

오늘은 지난 이슈 설명회를 했다!

 

오늘은 항상 고맙고 또 고마운 승원이와 오랜만에 온라인으로 만났다. 주제는 지난 Member 이벤트 발행 이슈와 관련하여, 원인이 무엇이었고, 어떻게 조치했는지를 이야기하기 위해 만났다.

 

관련 PR

Bug/fix missing member request message publisher(Member Event 발행 누락을 개선한다.) by KEEMSY · Pull Request #8 · KE

 

나는 무엇이 문제였고, 어떻게 했다는 것을 이야기 했다. 그리고 승원이는 이에 대하여 피드백을 해주었다.

 

해당 문제는 단순히 내가 Publisher 를 누락하여 생긴 문제였고, 누락한 Publisher 를 추가함으로써 해결하였다. 여기까지는 잘했다. 하지만 테스트를 작성하면서, 해당 부분을 어떻게 검증했는가? 를 이야기하면서부터 문제점을 인지할 수 있었다.

 

 

---

문제: 어떻게 이벤트가 정상 발행되었는지 확인 할 것인가?

 

CreateProductCommandHandler의 테스트의 일부분, 이벤트의 발행은 유스케이스에서 이뤄지며, 나는 유스케이스를 각 Handler 에서 처리한다.

 

이벤트의 발행은 유스케이스에서 해당 유스케이스를 처리하면서 이벤트를 발행한다. 그리고 나는 유스케이스를 Handler 를 통해 관리하도록 설계하였다. 그리고 나는 당시 테스트를 사진과 같이 작성했다.

 

publish 행위를 검증하면서, 사용된 이벤트의 객체가 내가 생성하는 정보를 갖고있는가? 를 검증했다. 정작 Kafka의 정상 이벤트 발행을 테스트 하지 않았다. 그리고 Kafka에 정상적으로 이벤트가 생성됬음을 확인하는  테스트는 작성하지 않았다.

 

승원이는 이 부분을 피드백 해주었다. 나는 외부서비스(환경)은 Mocking 을 해야한다 생각했다. 테스트 하는 대상에서는 외부 요인은 고려 요소가 아니기 때문이다. 이것이 틀렸다고 생각하지 않는다. 그렇다고 승원이의 피드백이 잘못됬다고 생각도 하지 않는다.

 

나는 승원이가 피드백해준 부분은 Messaging 계층에서 확인하면 될 문제라고 생각했다. 그러나 나는 Messaging 계층(Kafka 이벤트 발행 및 구독)을 테스트 하고 싶었으나, 해당 방법을 몰라 작성하지 못했었다. 그러면서 또 카프카 클러스터는 외부요인인데, 내부 요소만 정확하게 테스트가 이뤄지면 문제가 없는 것 아냐? 하는 잘못된 생각을 하게 되었다.

 

이는 실제 프로덕션에서 내가 책임지는 부분을 생각해본다면, 잘못된(?) 생각이었음을 깨닫게 된다. 나는 내가 담당한 서비스에 대해서 정상작동함을 보장해야한다. 이는 당연하다. 그렇다면 카프카 클러스터는 내 서비스가 아니라고 말할 수 있는가? 아니다. 명백하게 내 서비스의 일부분이며, 이 또한 내 서비스에서 정상작동함을 테스트를 통해 증명해야한다. 그리고 이를 위해서는 실제로 사용되는 부분, 유스케이스에서 검증이 되어야 한다.

 

승원이의 피드백덕에 해당 부분에 대한 생각의 확장(?)을 할 수 있게 되었다. 그리고 해당부분은 리팩토링 이슈로 등록하여 리팩토링 해볼 계획이다.

 

---

오늘은 여유롭게 한다며, 정말 여유를 부리다못해 여유속에 살았다.. 하고싶은 것, 해야하는 것은 많은데.. 내 자신이 조금(많이) 부끄럽다... 내일은 벌써 8월 3주차가 시작된다. 이번 3주차에는 기필코 Order 도메인을 1차 완료하고, 이슈 등록했던 Product 이슈를 해결하고 또 이력서를 업데이트해야겠다. 이것들은 할 수있겠지 !!!!!!!!! 할수있다!!!!!