Product Messaging 개발, 독서, 문제풀이

나 컨디션이 좋아진줄 알았는데, 아닌것같다. 날씨 너무 사악하고, 무엇 때문인지 잠을 못잔다.. 눈은 감기고 졸리는데, 감고 누우면 잠을 못잔다.. 왜이러는거냐 대체..  그래서 오늘은 오전에 독서하고, 하체운동을 정말 죽어라고 했다. 오늘은 쉽게 잠들 수 있겠지..?

 

---

Product 도메인 개발

오늘의 목표는 Product Adapter Messaging 을 개발하고, 지난 DataAccess 개발 간 식별한 유스케이스의 추가(동적쿼리를 통한 Product 조회) 를 이슈로 등록하고, Product 도메인의 Wiki 를 업데이트 하는 것이었다. 변명의 여지없이 내가 늘어져서 글을 쓰는 지금, Messaging 개발만 완료했다. 글을 다 작성하고, 남은 두개도 오늘 마치고 자야겠다.

 

---

Adapter.Out.Meesaging 개발

 

총 해야할 항목

• Avro 클래스 생성을 위한 avsc 파일 생성
• domain-application-output 내에 message.publisher 인터페이스 생성
• 생성한 인터페스를 구현하는 Publisher 구현
• Publisher 구현간 필요한 DataMapper, Helper 추가

---

Messaging 모듈에서는 avro 모델을 통한 직렬화를 활용하여, 카프카를 사용한다. 그래서 가장 먼저 나는 .avsc 파일을 작성했다.

 

현재 작성된 avsc 파일들, 생성되는 이벤트로 발행될 내용들이다.

 

나는 빌드 시, 해당 파일들을 읽어 자동으로 Avro 클래스를 생성하도록 설정했다. 나를 많이 괴롭(?)히고, 아직 생성되는 것이 내 맘에 들진 않지만, 자동으로 생성해주는 플러그인 자체만으로도 감사하다.

 

build.gradle 의 Avro 설정 부분

 

GitHub - davidmc24/gradle-avro-plugin: A Gradle plugin to allow easily performing Java code generation for Apache Avro. It suppo

 

빌드 시, 정상적으로 Avro 클래스들이 생성되는 것을 확인하고, 나는 다음 개발을 진행했다.

 

• Avro 클래스 생성을 위한 avsc 파일 생성
• domain-application-output 내에 message.publisher 인터페이스 생성
• 생성한 인터페스를 구현하는 Publisher 구현
• Publisher 구현간 필요한 DataMapper, Helper 추가

 

첫번째, message.publisher 인터페이스 는 각 유스케이스에 맞게 분리하여 작성하기 위해 개발한다.

생성 발행자를 위한 ProductCreatedRequestMessagePublisher

한곳에서 관리할 수 있지만, 유스케이스별로 각각의 입력/출력 모델이 존재하듯이, 이벤트 생성자 또한 분리하여 개발하였다.

 

ProductCreatedRequestMessagePublisher를 구현한 CreateProductKafkaMessagePublisher의 일부분

솔직하게 나는 지금  부분은 자세하게 알지 못한다.. 이전 프로젝트에서 이렇게하니깐 이벤트 발행이 되던데? 하여 해당 코드를 참고하여, 지금 프로젝트에 맞기 응용했다. 이렇게 보니, 빨리 카프카도 공부해야겠다.. 카프카가 왜 좋은지, 이론적인 부분만 알고 있어서... 하하... 부끄럽다.... 어떻게 스프링과 함께 동작하는지.. 사용할 수 있는 방법에 대해 조금 더 깊게 공부해봐야겠다.

 

MessagePublisher에서 사용되는 MessagingDataMapper 는 이벤트로부터, Avro 클래스로 매핑하는 역할을 하고, Helper 는 각 도메인 내의 MessagPublisher에서 공통되는 부분(콜백)을 같이 사용할 수 있도록 모듈화 하였다.

 

ProductKafkaMessageHelper 클래스, 각 도메인 별로 KafkaMessageHelper 가 존재한다.

그런데 지금보면, 거의 똑같은 KafkaMessageHelper 가 Member, Product 에 같이 존재한다.. 이를 개선하지 않으면, 앞으로 개발 될 도메인들에서도 계속해서 KafkaMessageHelper가 생성될 것이다.. 이럴순없다. 공통으로 사용할 수 있는 KafkaMessageHelper 방법을 고민해봐야겠다.

 

다른 UpdateProductKafkaMessagePublisher 도 같은 과정을 반복하여 개발을 완료하였다.

 

• Avro 클래스 생성을 위한 avsc 파일 생성
• domain-application-output 내에 message.publisher 인터페이스 생성
• 생성한 인터페스를 구현하는 Publisher 구현
• Publisher 구현간 필요한 DataMapper, Helper 추가

 

근데 이거 테스트는 어떻게 해야하지...?

---

독서: 만들면서 배우는 클린 아키텍처

 

얇지만, 정말 많은 내용이 담겨있는 만들면서 배우는 클린 아키텍처 책을 완독했다. 관심있는 주제였고, 평소 궁금했던 내용을 이책을 통해 공부해 볼 수 있었다. 책의 내용을 완전히 내것으로 만든 것은 아니지만, 다른 사람들에게 이 프로젝트의 구조를 설명할 때, 근거 있는 설명을 하는데 큰 도움이 되었다. 그런데 최근 PR을 거치면서 이 아키텍처는 뭐가 좋은거지? 라는 생각이 문득 들었었다.

 

나는 클린아키텍처(Ports and Adapters) 를 적용한 프로젝트를 만들어보고 싶고 공부해보고싶어 지금의 프로젝트를 만들었다. 이 프로젝트는 일반 대중화된 MVC(계층형 아키텍처)와는 크게 다른 구조를 띄고 있다. 익숙하지 않은 다른 것을 사용한다는 것은 다른사람들에게 납득이 될만한 이유없이는 선택되지 않을 것이다.

 

 이 아키텍처 구조를 따른다면? 도메인을 외부 관심사(영속성 계층, 웹계층 등)로부터 분리한다. 그리고 모든 의존성의 방향이 도메인을 향하게 되면서, 도메인은 SRP(단일 책임 원칙)을 따르게되고, 변경할 이유가 단 한가지, 도메인 로직의 변경만이 존재하게 된다.

 

나는 클린 아키텍처의 장점을 다시 생각해보기 시작했다. 첫번째로 명확한 경계를 얻을 수 있다. 그리고 명확한 경계는 테스트를 용이하게 한다. 도메인 외에 수많은 다양하고 복잡한 외부요소를 고려하지 않고서 단위테스트를 쉽게 작성할 수 있으며, 이는 프로젝트 개발에 아주 큰 이점이다.

 

그리고 어댑터를 기준으로 동시작업이 가능해진다.(계층형에서는 불가능하다.) 명확하게 나눠진 계층으로 인해, 각 계층은 독립적으로 확장 수정 할 수 있다.(명세만 지킨다면) 이외에 DDD(도메인 주도 설계)의 이점 또한 모두 얻을 수 있다.

 

장점을 나열하면, 안하는게 손해인 그런 아키텍처이다. 그런데 왜 리뷰 간 사람들에게 흥미가 아닌의문만 가득 안기게 된걸까?(의문이 아닐수도 있지만 내가 그렇게 느껴졌다.) 나는 중요한 요소 한가지를 빠트렸었다. 언제 이 아키텍처를 적용해야하는가? 이다. 이 아키텍처가 필요로 하는집단, 순간에서 이야기가 됬다면, 엄청난 흥미요소가 되었을 것이라고 생각이 들었다. 내 자신만 봐도, 어떻게하면 도메인별 분리된 서비스(MSA)를 할 수 있을까? 에서 시작하여, 어떻게하면 DDD 를 성공적으로 할 수 있는 아키텍처이지?(이에 대한 답을 단순하게 MVC 아키텍처라고 생각했다.)  > MVC는 지금 구조랑 똑같은데, 그럼 지금 문제가 발생할 수 있는거잖아? > 클린아키텍처? 의 순서로 클린아키텍처에 관심을 갖게 되었다.

 

 

 

아키텍처에서 추구하는 가치, 집단이 추구하는 가치를 고민해봐야한다.

 

마지막 책의 부분을 읽고서, 이 질문의 답과, 내가 가야할(가고싶은) 집단의 모습을 조금 더 구체화 한 것 같다. 나는 도메인이 중심이되는, 코드개발에 있어, 독립적으로(병렬적으로) 개발할 수 있는 프로젝트를 담당하는, 올바른 코드 개발을 할 수있는 집단을 선택해야겠다.

 

누군가는 분명 책은 이상적인 내용이고, 현실은 그렇지 않다고 이야기할 것 이다. 근데 내 생각에는 이상적인 모습이 떡하니 있는데, 이걸 이상이라고 할 수 있을까? 충분히 할 수 있는 내용이라고 나는 생각한다. 하지만 이 생각도 혼자서는 할 수없다. 그래서 나는 이런 생각을 하는 집단에 갈것이다~!

 

---

오늘은  날씨에 늘어지고, 잠도 잘못자고.. 핑계는 그만하고 내가 게으르고 의지가 나약해서 목표한 바를 주어진 시간내에 해내지 못했다.

이에 대해 반성하면서도, 큰 아픔 없이 이런 고민과 개발을 할 수 있음에 감사하며, 내일은 더 나은 내가 될 수 있도록 더 열심히 해야겠다.

 

 

벌써 일주일의 절반이 다지나갔다니.. 빨리 PR 작성하고, 대망의 Order 도메인을 개발하고싶다 ~~!!