[공부 시간 기록/개발일지] (3) DTO, VO, ??? 그럼 DDD끼리 데이터 교환은? 아니 그전에 동기 비동기가 뭔지부터 알아야지

1. 이번엔 또 뭔데?

앞서서 나는 WakaTime에서 access토큰을 받아오고 저장하는 모듈을 만들었다. 이모듈은 access토큰을 받아오고 저장하는 단일 기능역할을 수행할 것임으로 access토큰을 사용해서 사용자의 데이터를 저장하는 모듈을 다른 모듈이 될것이다.

자 그럼 이런 방식에서 고민해야하는것이 뭘까? 그럼 뿌려주는 방식이 뭘까? 라는 물음에서 시작됐다.

(DB설계는 다했는데 이거 고민하느라 데이터 저장은 시작도 못한것은 비밀)

2. 아직 통신방식은 안정했다. 물론 넘겨줄 데이터 형식도 안정했다. 

통신방식은 아직 정하지 않았다. 이유는? 어떤 객체? 데이터 형식?을 넘겨줄지 정하지 않았는데 무작정 통신 방식을 정한다? 이것도좀그렇고.. 그래서 같이 비교해보려고한다. 어떤 통신법에서 어떤 방식으로 넘겨주는것이 좋을지 같이 고민하며 동기 비동기에 대해서 얘기하는 글을 보자고 글쓰다보면 동기 비동기 빼고는 다음글로 넘어갈지도...?

3. GPT야 도와줘!

GPT의 도움을 통해서 추천받은 항목은 아래와 같다.

구분	방식	설명	장점	단점	데이터 형식	동기 가능	비동기 가능
1	REST API	HTTP 요청으로 모듈 호출	간단, 범용적	강결합	JSON, DTO	✅ 가능	❌ 불가능
2	FeignClient	선언형 REST 호출	유지보수 용이	강결합	JSON, DTO	✅ 가능	❌ 불가능
3	WebClient	논블로킹 HTTP 호출	리액티브	복잡함	JSON, DTO	✅ 가능	✅ 가능
4	메시지 큐 (Kafka 등)	이벤트 기반 처리	비동기 확장성	디버깅 어려움	JSON, Avro, Protobuf	❌ 불가능	✅ 가능
5	공유 DB	DB 통해 데이터 공유	빠름	DDD 위배	DB Entity, View	✅ 가능	❌ 불가능
6	공용 라이브러리	로직 재사용	일관성 유지	배포 의존	Java 객체, DTO	✅ 가능	❌ 불가능
7	gRPC	고성능 RPC	빠름, 명확한 스키마	환경 설정 필요	Protobuf	✅ 가능	❌ 불가능

동기 비동기는 왜 정리했나요?

자 상황을 한번 보자고

주문 배송 흐름을 한번 생각해보자

1. 주문  생성
2. 재고 차감
3. 결제 승인
4. 배송 요청
5. 알림 발송
6. 포인트 적립

1번 주문이 생성됐다. 고객이 물건을 요청해요~ 를 보냈다.

그럼 주문을 받는 모듈은 주문을 받고 재고를 확인하는 모듈에 재고가 있나요? 재고차감 할께요 를 보내야한다.

이거 살수있나요? -> 재고차감했어요 직후 여기서 장애가 생기는 걸 생각해보자

항목동기 처리비동기 처리

1.주문 요청	클라이언트가 주문 요청함	클라이언트가 주문 요청함
2.재고 차감	재고 차감 즉시 반영됨	이벤트 큐에 전달됨
3.장애 발생 (예: 주문 DB 장애)	차감은 됐는데 주문은 실패 → 재고 불일치 가능	주문 저장 안 됨 → 큐에 쌓인 재고 이벤트도 안 처리됨
보완 방법	트랜잭션 묶거나 롤백 필요	이벤트 소비 전 DB 확인 가능 (idempotent 처리)
장점	일관성 보장 쉬움 (트랜잭션 내 처리)	장애 격리 쉬움, 재처리 가능
단점	장애 시 롤백 복잡	재고와 주문 상태 싱크 맞추는 로직 필요

 

내가 생각한 각 단계의 동기 비동기는 이러하다.

1. 주문 생성 :
   주문번호 및 사용자응답을 즉시 해줘야하며 트렌잭션 범위가 적어서 동기처리가 더 유리하다. 이벤트도 가장 앞단에 있어 장애 전파도 적다.
2. 결제 :
   결제가 실패하면 주문 실패를 즉각적으로 알려줘야하며 실패를 기록해야한다. 주문 생성과 같은 트렌잭션에 있어야하며 이는 동기처리를 함을 의미한다.
3. 이후 재고 차감 부터 알림, 포인트, 로그, 배송 요청 등등 :
   빠른 속도를 요구하지 않는다. 또한 여기 과정에서는 장애가 생겨도 주문, 결제를 실패시키기 보다 재시도 및 재처리가더 유리하다. (재고가 없으면 나중에 취소하고 알람을 줘도 되겠지?)

그니까 내가 생각한 중요한점은 고객이 즉각적인 답을 받아야하는 부분 (주로 처리과정의 앞단이겠지?)는 장애가 전파될 곳도 적고 정확성 및 즉시성이 더 중요해서 동기로 처리하고, 이후부분들은 장애를 격리할 수 있는 비동기가 더 유리하다는 생각이다.

 

내가 만드는건? waka accessToken을 사용하는 곳은 전부다 비동기로 처리해도된다. api를 사용해서 waka쪽에서 데이터를 받아올때 선행되야하는 것이 없는 구조로 DB를 설계했기 때문에 데이터 동기화가 필요없고 병렬처리를 진행해도 된다. (나중에 batch로 해볼예정이다.)

그래서 내가할꺼는 일단 webclient로 진행할 것이다. 이유는 다음과 같다.

Kafka 왜안씀 핵심 기술스택아님?

나는 지금까지 기술을 깊게 이해하기보다는 주로 넓게 사용했던거 같다. 그래서 이번엔 최대한 자바 로직에 집중해보려고 한다. 또한 다른 툴의 도음을 받으면 정말 좋겠지만 GCP의 무료 티어를 사용해서 최대한 비용도 절감할 예정인 나에게 kafka처럼 무거운걸 돌릴수도 없어서(spring만으로도 벅차다...) webclient로 진행하려고한다.

 

어차피 나는 DDD의 output설계를 최대한 추상화할꺼다. 나중에 상황이 좋아지면 webclient또한 바로 kafka로 변경하는 DDD의 강점을 활용할수 있지 않을까?