오늘 패키지 구조를 팀원들과 정했다.팀원중 한분이 아프셔서 오늘 불참해서 매우 슬프지만ㅜㅜ 암튼 우리는 패키지 구조를 정했다.튜터님이 몇일전에 글을 올려주셨는데 DDD관련 글이었다.그 글을 보고 어떻게 구성하면 좋을지 고민을 해보았습니다.1차때 패키지 구조를 논의하지 않아서 리펙토링을 하는것이 어려웠다.그래서 이 구조를 선택하게 되었다.하지만 생각보다 쉽지 않는 구조에 튜터님을 계속해서 방문해서 그 해답을 듣게 되었다.우리가 결정한 아키텍처는 4 레이어 아키텍처로상위패키지├── application├── domain├── infrastructure└── presentation크게 이렇게 결정하였다.간단히 설명하면 application은 무조건 domain이랑 소통을 해야 한다는 점이다.그리고 외부에서 받..
2차 프로젝트가 시작이 되었다.이번에는 나는 팀장이 아니라 팀원으로 시작하였다.근데 왜 내가 테크 리더....뭐지... 왜 감투를 쓰게 된거지저번 프로젝트는 배민이었다면 이번에는 쿠팡이다. 다만 다른점은 쿠팡은 물류창고가 있지만이 프로젝트는 허브가 물류창고 개념은 아니라고 하셨다.오늘 실업급여때문에 고용센터를 갔다오는 바람에 12시에 입실을 하였다.도착하니 팀원들이 API명세서를 작성하고 있었다.근데 나는 API명세서 보다 기획 흐름을 먼저 알아야 된다고 생각했고플로우 차트 부터 그리자고 하였다.그 결과 요런식으로 작성하게 되었다.플로우 차트를 그리고 보니 저녁이 벌써 9시가 넘었다. 분명 기획을 읽었는데 너무 허점이 많았고.. 힘들었다.하지만 너무 재밌게 해결했던거 같다.그리고 이번에는 chat gpt..
프로듀서..@Bean public ProducerFactory producerFactory() { Map configProps = new HashMap(); // 중간 구현 return new DefaultKafkaProducerFactory(configProps); } // 동적으로 만들고 @Bean public KafkaTemplate kafkaTemplate(ProducerFactory producerFactory) { return new KafkaTemplate(producerFactory); } // 구체화 시키고 @Bean public KafkaTemplate demoCreateEventKafkaTempla..
음 사가가 뭘까..saga: 서비스들이 이벤트로 협력해서 트랜잭션을 완성하는 방식Saga 패턴은 분산 시스템에서 트랜잭션을 처리하는 방법 중 하나로, 데이터베이스의 일관성을 보장하기 위해 여러 서비스 간의 복잡한 트랜잭션을 관리합니다. 이를 통해 마이크로서비스 환경에서 발생할 수 있는 트랜잭션 처리 문제를 해결할 수 있습니다.요렇다고 한다.그러면 주요 특징은 어떤것이 있을까분산 트랜잭션 관리:전통적인 분산 트랜잭션에서는 한 번에 모든 작업을 완료해야 하기 때문에, 여러 서비스가 참여할 때 데이터의 일관성을 유지하기가 어렵습니다.Saga 패턴은 각 서비스에서 로컬 트랜잭션을 처리하고, 각 로컬 트랜잭션의 성공이나 실패에 따라 후속 작업을 정의합니다. 즉, 트랜잭션을 여러 단계로 나누어 관리합니다.그니까 사..
Saga 패턴은 ACID 대신 BASE 원칙을 따르는 대표적인 기법 BASE는 Basically Available, Soft state, Eventual consistency의 약자야. 하나씩 간단하게 볼게!Basically Available(기본적인 가용성)시스템이 항상 완전한 일관성을 보장하지 않더라도, 항상 응답은 가능한 상태를 유지해. 일부 데이터가 최신이 아니더라도 서비스는 계속 동작하는 거지.Soft state(유연한 상태)데이터의 상태가 즉시 일관적이지 않아도 괜찮음. 각 서비스가 독립적으로 데이터를 관리하니까, 시스템 전체의 상태가 시간이 지나면서 변할 수 있어.Eventual consistency(최종적인 일관성)즉시 일관성을 포기하는 대신, 일정 시간이 지나면 결국 데이터가 일관된 상태..
카프카는 어떤것일까 내가 알기로는 카프카는 대규모 트래픽 환경에서 사용한다고 한다.생각해야 할것이 진짜 카프카가 대규모 트래픽 환경에서 좋은걸까? 좋다면 왜 좋은지 알고 있어야 한다고 생각한다.사가패턴이며, 이벤트 소싱이며 이런거 보다 진짜 중요한건 카프카가 왜 필요한지 여부에 대해 공부를 해야 한다고 생각한다.모든 기술이 그렇듯 다 탄생 배경이 있다. 그렇다는건 어긋난 방식으로 사용한다면 오히려 성능이 떨어질 수 도 있다는 뜻이 된다.이 글에서 어떻게 사용하는지에 대해는 자세하게 다루지 않을 수 도 있다. 이것도 보다 중요한건 왜 쓰고 언제 쓰는지가 훨씬더 중요하다 생각한다. 이제 본격적으로 시작해보자.카프카의 탄생 배경대규모 데이터 처리 필요성: 대규모 분산 시스템에서의 로그 처리와 실시간 데이터 스..
스프링 시큐리티 (Spring Security)는 스프링 기반 어플리케이션의 보안(인증과 권한, 인가)을 담당하는 스프링 하위 프레임워크.보안과 관련해서 체계적으로 많은 옵션들을 제공해주기 때문에 개발자의 입장에서는 하나하나 보안 관련 로직을 작성하지 않아도 된다는 장점이 있다.특징과 구조보안과 관련하여 체계적으로 많은 옵션을 제공하여 편리하게 사용할 수 있음Filter 기반으로 동작하여 MVC와 분리하여 관리 및 동작어노테이션을 통한 간단한 설정Spring Security는 기본적으로 세션 & 쿠키 방식으로 인증인증관리자(Authentication Manager)와 접근 결정 관리자(Access Decision Manager)를 통해 사용자의 리소스 접근을 관리인증 관리자는 UserNamePasswor..
스프링 이벤트(Spring Events)는 애플리케이션 내에서 컴포넌트 간의 느슨한 결합(loose coupling)을 유지하면서 비동기적 또는 동기적으로 메시지를 전달하는 메커니즘입니다.스프링의 Observer 패턴 기반으로 동작하며, 특정 이벤트가 발생했을 때 이를 감지하고, 이에 대한 처리를 수행하는 구조입니다.1. 스프링 이벤트의 구조Event (이벤트): 발생한 상황을 나타내는 객체. ApplicationEvent를 상속하거나 일반 POJO로도 이벤트를 정의 가능.Publisher (발행자): 이벤트를 발생시키는 주체. ApplicationEventPublisher를 사용해 이벤트를 발행.Listener (리스너): 이벤트를 구독하고 처리하는 주체. @EventListener 어노테이션으로 구현..