Architecture

외부DB - repository - service - controller - FE도메인만을 담당실질적인 작동하는 하는 부분DB와 연결을 담당개발과정에서 스파게티 코드를 막게 하기위해 각각의 모듈은 서로가 하는 일을 할 수 없어야하고 알 수 없게 해야한다. 실제로 개발

최근 신규 프로젝트를 하면서 다른 프로젝트를 참고하다보니 모듈의 구조를 조금 바꾸어 보았다. 이전의 프로젝트에서 service모듈을 독립적으로 두었지만 모노레포방식으로 서버를 한 개 더 추가했을때 애매해졌다. 그 때의 경우에는 백오피스 서버를 하나 더 구축하는 것이었는

최근 아키텍쳐와 비즈니스로직에 대해 가독성있고 유지보수성이 떨어진다고 생각하여 개선된 멀티모듈 아키텍처를 만들었습니다.기존에 Service단에서 해당하는 Repository 뿐만 아니라 다른 Repository까지 의존성이 높아져 Service 함수의 재사용성이 많이

Kafka는 기본적으로 at-least-once 전달을 보장한다. 메시지가 반드시 전달되지만, 한 번만 전달된다는 보장은 없다. 컨슈머가 메시지를 처리한 직후 커밋 전에 재시작되거나, 리밸런싱이 발생하면 같은 메시지를 다시 받게 된다.컨슈머 재시작 시나리오브로커가 of

이전 글에서는 Kafka Consumer가 중복 메시지와 순서 역전을 어떻게 처리하는지 다뤘다. 그런데 Consumer를 아무리 견고하게 만들어도 메시지가 애초에 발행되지 않으면 소용없다.이번 글은 반대쪽, Producer의 신뢰성 문제를 다룬다. "도메인 변경과 Ka