인프런 커뮤니티 질문&답변
작성한 질문수
domain.model.event에 정의되는 객체들에 대한 질문이 있습니다
해결된 질문
작성
·
255
0
MSA강의 재밌게 잘 보고 있습니다 👏
강의를 보던 중 카프카 연동을 위해 kafkaadapter와 event 패키지를 정의하고 객체들을 넣고있는데, 저희 회사에서도 겪고 있는 문제가 떠올라서 궁금한게 생겼는데,
프로듀싱하는 서비스와, 컨슘하는 서비스의 프로토콜을 ItemReturned, ItemRented등으로 정의하고 내부 값에서IDName등을 사용한다고 할 때 이 프로토콜 스펙이 변경될 때마다 각 팀별로 객체 정보를 수정한다고 하면, 마치 서비스내에 코드 중복들이 된 상태에서 기능이 변경될때마다 중복된 코드들을 같이 관리하며 싱크를 맞춰줘야하는 작업들과 유사해보이는데, 이에 대해서는 어떻게 풀어나가야 하나요?
즉, 서비스간에 데이터 송수신을 위한 객체들이 중복코드처럼 보이는데 스펙변경이 있을때마다 각 서비스마다 직접 코드 수정을 하는건 한 팀에서 수정을 누락하거나 관리를 놓친 프로젝트에서 수정이 누락되면 문제가 될 수 있을 것 같은데 어떤식으로 풀어나가는지 궁금합니다.
답변 1
2
네 안녕하세요.
항상 저도 프로젝트를 할 때 마다 고민되는 부분을 어려운 질문주셨네요. 움 이러한 관계는 사실 기술 거버넌스에 관한 문제이기도 한 것 같아요. 우선 서비스를 소유하고 있는 조직 또는 팀의 역학관계에 따라 다양한 방안이 고려될 수 있을 것 같네요. 그런 부분을 논한 부분이 도메인 주도 설계의 서비스 매핑 패턴인데 상위스트림 서비스와 하위스트림 서비스 간의 관계를 설명하고 있는데 한번 참고해 보시고요.
그리고 해결방안은 기술 적인 부분보다는 협업의 문제인것 처럼 느껴집니다.
우선 도메인 이벤트를 생산하는 생산자와 이를 소비하는 소비자의 관계는 Contract-First Design 라는 관점으로 봐야 할 것 같습니다. 이벤트가 아니라 API라고 생각하면 쉬울 것 같네요.
따라서 각 생산자와 소비자는 코드를 직접 수정하기보다는 먼저 명확한 계약이나 인터페이스 사양을 정의하고 유지할 필요가 있겠죠. 참여 팀은 이 계약에 동의하고 이를 준수하고 변경이 필요할 경우 반드시 이전에 합의가 필요할 것 같고요.
또 이것을 중복 로 생각할 수 도 있을 것 같은데요. 마이크로서비스는 서비스의 자율적인 배포를 위해 어느정도의 중복을 통한 느슨한 결합을 추구한다고 생각하셔도 될 것 같네요. ^ ^;;;
이벤트가 아니라 API로 생각하라고 하니, 이해가 되었습니다.
api 스펙이 변경된다면 그 전에 미리 고지를 해서 변경될것을 알려주고, 이를 각 클라이언트가 준수해야하는 것처럼요.
또는 라이브러리의 @Deprecated 애노테이션과도 비슷할 수 있겠네요!
답변 감사합니다!