EDA 이해

23.11.17 20:43 작성 조회수 236

EDA가 결국 이벤트를 기반으로 비즈니스적으로 응집력 있게 관리되어야 하는 데이터들을 어떻게 핸들링할 것인가 인것 같은데, 제가 맞게 이해한 걸까요? 이를 위해서는 결국 도메인 중심적으로 생각하는게 좋구요!

EDA 기반 Microservice 구현 (with Hexagonal, DDD)

답변 1

답변을 작성해보세요.

han jeong heon

2023.11.19

아 네

아마도 강의에서 도메인 주도 설계 를 기반한 EDA를 구현을 해서 그렇게 느끼신 것 같습니다.

그러나 EDA 라는 개념은 물론 도메인주도설계와 궁합이 잘 맞지만 반드시 DDD기반일 필요는 없습니다.

도메인 상태의 변화를 기반으로 한 즉 이벤트를 비동기 통신을 통해 전달함으로써 어플리케이션간의 결함도를 낮추는 아키텍처가 EDA인 것이고 그 어플리케이션형태는 규정되지 않습니다.(모노리스가 되도 되고 마이크로서비스가 되도 되고요.)

다만 MSA를 언급할때 EDA라는 아키텍처가 마이크로서비스간의 의존성을 낮추기 위한 용도로 궁합이 잘 맞는다고 생각하시면 될 듯합니다.

백린이

2023.11.19

아하! 그럼, EDA를 강의처럼 kafka가 아니더라도, AWS SQS, rabbitmq 등 다양한 솔루션을 사용할 수 있는건가요? 대규모 시스템이라면 kafka가 좋을 수도 있겠지만ㅎㅎ

han jeong heon

2023.11.19

아 네 그럼요 ^ ^

백린이

2023.11.19

빠르게 답변주셔서 감사합니다!ㅎㅎ
한가지 더 궁금한 점이 있는데, usercase 별로 인터페이스를 만드셨는데, 혹시 1개의 인터페이스에 여러 메서드를 통해서도 만들 수 있는데, usercase 별로 인터페이스를 만드신 이유에 대해서 여쭤봐도 괜찮을까요?

han jeong heon

2023.11.19

네 말씀하신데로 하나의 인터페이스로 작성해도 기능상 문제는 없습니다.

즉 이러한 방식은 관리나 유지보수 차원의 선택인데요.

로버트 마틴이 언급한 ‘ 소리치는 아키텍처’ 라는 개념이 있는데요. (코드의 명칭을 통해 그 의도롤 소리치게 하자.) 즉 클래스 명만 보고 어떠한 유스케이스인지 쉽게 인지 가능함으로 유지보수성 높일 수 있다는 의미죠.

따라서 이 부분은 유지보수하는 팀원 수라던지 상황에 따라 다를 수 있는 선택의 문제입니다.

감사합니다.

백린이

2023.11.19

아하! 지금 생각해보니, 어떻게보면, usercase 별로 인터페이스를 만들어두면, github으로 협업할 때, 팀원들끼리 충돌 발생이 적겠네요?ㅎㅎ