DDD 이벤트 스토밍

마이크로 서비스 간의 의존 관계를 명확히 하기 위해 DDD 이벤트 스토밍을 해봤다.
한 번 해보니까 서비스 사이의 메시징을 어떻게 구성해야 하는 지 한 눈에 알 수 있었다.

참고 서적 및 링크

위 이벤트 스토밍은 도메인 주도 설계로 시작하는 마이크로 서비스 개발의 절차대로 했으며, 아래 링크에서도 절차가 소개되어 있다.

https://engineering-skcc.github.io/microservice%20modeling/Event-Storming/

중간 점검

1. 각 서비스 내 인증의 경우 JWT토큰을 전파하는 방식으로 해야 할 것 같다.

2. 임시 저장 버튼을 추가하고 레디스를 활용하려 한다. 나중에 일지 작성 화면에 진입하면 레디스에서 불러오게 구현할 예정.

3. 카프카 메시징에서 원본 데이터를 보내는 것은 좋지 않다. 그래서 id 값이나 db 풀링 방식을 이용해 일관성을 맞춰야 한다. 일지 CUD 작업이 일어나면 R 서비스에 풀링하라고 메시지를 보낼 예정이다. 그런데 어떻게 구현할 지는 조사를 많이 해봐야겠다.

4. 카프카 메시지의 Sequential order를 보존할 수 있는 방법도 조사해야 한다. 싱글 파티션 또는 같은 파티션 내라면 순서가 보존된다는데, 확실하고 충분한 지 알아볼 필요가 있다. 다른 방어적 코딩은 필요 없나?

5. 프론트엔드 단은 기존 모놀리식 재탕할 예정.

6. 배포는 AWS lightsail. AWS 프리티어 다 끝나가고, 무료인 oracle cloud는 가입도 안된다. 그래서 가격이 싼 lightsail을 이용한다. 그리고 비용을 극한으로 줄이기 위해 AWS 매니지드 서비스는 사용하지 않으려 한다. (lightsail 내 db, 컨테이너 서비스 등) 대신 직접 설치하고, 내가 알아서 관리해야겠지만...

rds VS 직접 설치 비교한 링크

https://dingrr.com/blog/post/rds%EB%A5%BC-%EC%8D%A8%EC%95%BC-%ED%95%98%EB%82%98%EC%9A%94-ec2%EC%97%90-%EC%84%A4%EC%B9%98%ED%95%98%EB%A9%B4-%EC%95%88%EB%90%98%EB%82%98%EC%9A%94