일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 카프카
- 스프링
- 플러터 개발
- 자료구조공부
- 스프링공부
- 스프링부트
- JPA
- Axon framework
- 플러터 공부
- 알고리즘공부
- Kafka
- JPA공부
- 스프링부트공부
- JPA예제
- DDD
- nestjs스터디
- Flutter
- JPA 공부
- K8S
- querydsl
- nestjs
- 기술공부
- 스프링 공부
- 코테공부
- 자바공부
- 프로그래머스
- JPA스터디
- nestjs공부
- 코테준비
- 기술면접공부
- Today
- Total
목록Develop/[DDD] (24)
DevBoi
비슷하면서도,,, 느낌이 오면서도.,,,, 무튼 다른,, 그런 두가지 어노테이션을 공부해보려고한다. @TransactionalEventListener는 해당 쓰레드가 언제 트랜잭션을 처리할지, Phase를 통해서 정의할 수 있다. @EventListener는 호출시점에 바로 실행된다. 트랜잭셔널이벤트리스너는, 아래와 같이 4가지 Phase를 나눠서 등록이 가능하다. @Component class MemberEventHandler { @EventListener fun defaultEventListener(event : MemberSave){ logger.info("defaultEventListener ---> {}", event) } @TransactionalEventListener(phase = Tran..
EventListener가 어떻게 등록이되고 캐치가 될까? applicationEventPublisher는 Event를 받아, 리스너들에게 Event를 Publish해준다. 도대체 어떻게 무슨 원리로 Publish 되는걸까 ApplicationEventPublisher 인터페이스는 아래 4개의 곳에서 재 정의한다. 그리고, 보통은 AbstarctApplicatonContext에서 정의한 걸 따라간다. AbstractApplicationContext - publishEvent 중요한 부분은 아래이다. Multicaster에게 작업을 위임한다. SimpleApplicationEventMulticaster의 내용이다. 보면 알다싶이, 이벤트 타입을 받아오고, getApplicationListeners를 통해서..
생소한 단어들일 수 있다. DDD를 하지 않으면, 잘 모른다. 우선, 공부를 해보자. Notification은 전파, 전달에 대한 기능을 구현하는 모듈이다. Event가 발생했을때, Notification을 주어서, 특정 이벤트를 발생시키는것이다. Outbox패턴으로 작업한다면, 이벤트를 저장하고, 배치나 스케줄러를 통해서 적정 단위로 처리된다. 이벤트 소싱과 Notification은 다르다. Notification이란, Repository에서 애그리게잇을 가져올때 이벤트를 사용해서 재구성한다. 재구성 하기 위해서는 이벤트 소싱이 가장 중요하다. 특정이벤트를 관심있어 하는 주체에 대해, Notification이 발동된다. Notification은 이벤트 소싱에 저장된 일련의 애그리게잇, 주체에게 이벤트를..
Axon framework 에서 command를 사용할때는 CommandBus, Event는 EventBus를 통해서 전달되었다 Query도 QueryBus를 통해서 해당 구현에 대한 Handler로 전달이 된다. 1. pointing query 해당 관련되서, 가장 간단한 구조이다. 각 핸들러를 미리 App에서 등록하고, 해당 요청이 오면 알맞은 Handler를 통해서 결과를 반환하는 것이다. 2. Routing 구조 멀티 모듈을 사용할때는 위와 같은 구조로 이루어 진다. 해당 관련되서, Axon Server에서 라우팅 테이블에 관련된 queryHandler를 등록해서, 사용자가 요청이 오면, 알맞은 앱으로 전달 및 결과를 요청 앱에 등록한다. 우선 해당 간단한 쿼리 클래스를 만들자 public cla..
공식 문서를 참조해서, 정리했다. Event Bus, Event Store의 개념에 대해서 정리를 하고, 쿼리에 대한 개념을 정리해보자. 1) Event Store Event를 읽고 쓰는데 있어, EventStore가 기본적으로 갖출 조건이 있다. 1. 이벤트는 추가만 가능하다, 입력 삭제,수정이 불가능하다. 2. 여러 이벤트가 하나의 트랜잭션에서 처리가 되어야 한다면, 트랜잭션 단위로 커밋,롤백 되어야한다. 3. 커밋된 이벤트는 유실되어서는 안된다. 4. 발행된 모든 Event중 Aggregate별로 데이터를 읽을 수 있어야 한다. 5. 모든 이벤트는 삽입된 순서대로 읽기가 가능해야한다. 6. Snapshot 저장소 지원 이벤트 저장소에, Aggregate에 대한 ID와 시퀀스 번호가 있다. 그리고 해..
일단 Query를 사용해봤다. 다음에는 Event를 사용해보자 마지막에 분석 및 기타 기능에 대해서 구현 및 포스팅을 할 것같다. 이번에는 생성에 대한 컨트롤러 단, 부터 생성을 해보자. 단순히 한개의 OrderCount를 늘린다. CQRS는 커맨드와 조회를 나눠, 조회와 데이터 변경에 대한 관심사를 나눈다. 1) OrderController @RestController public class OrderController { @Autowired private CommandGateway commandGateway; @PostMapping("/order/{order-name}") public CompletableFuture incrementProduct( @PathVariable("order-name") S..
이제 어느정도 구현에 대한 감을 잡았다. 실제적으로 사용하기 위한 코드로, Service부터 따라가며 구현을 리팩토링 해보자 우선 서비스 부터 다시 만들어야 한다. 분석기반으로 소스를 하나씩 구현해보자, 단순히 메소드 하나만 우선 사용을 할 예정이다. 1) OrderQueryService @Service @RequiredArgsConstructor public class OrderQueryService { private final QueryGateway queryGateway; public CompletableFuture findAllOrders(){ return queryGateway.query(new FindAllOrderedProductsQuery(), ResponseTypes.multipleIns..
간단하게, 음식과 관련된 애플리케이션을 만들어보자, 일단 구조는 기본적으로 잡아보자. Command,coreapi,query 단순히 이렇게 3가지 패키지만 만들어보자 기능은 뭐 단순히 신규 주문생성, 주문 확정,주문 배송 이렇게 두면 될 듯하다. 일단 생성한 커맨드는 아래 3개와 같다. 1) Commands @RequiredArgsConstructor public class ConfirmOrderCommand { @TargetAggregateIdentifier private final String orderId; } @RequiredArgsConstructor @Getter @ToString public class CreateOrderCommand { @TargetAggregateIdentifier pr..
바운디드 컨텍스트는 .. 그냥 뭐 여러가지 커맨드 액터 들을 얼마나 그룹핑 할것이냐...정도를 정하는 것이다. 대여 회원 도서 베스트 도서 로그인 이런식으로 바운디드 컨텍스트를 나눌수있고, 아까 정리했던 것들을 위의 분류 기준으로 나눠서 경계를 지정한다고 생각하면된다. 스케일 아웃이나, 여러가지 모듈을 나누는 기준이라고 생각하면 된다. 이런식으로 바운디드 컨텍스트가 나누어 지고 해당 바운드 컨텍스트 기준으로 보면 좀더 깔끔한 느낌을 받을수 있다. 정책이나, 모듈, 흐름에 대한걸 좀더 깔끔하게 보기 좋게 정리가 가능하다. 바운디드 컨텍스트도 핵심,일반,지원에 대한 종류가있다. 쿠팡으로 치면 배송이 핵심이고, 이 도메인이라고 치면, 대여에 대한 기능이 핵심 기능이 될 수 있어서, 대여에 대한 바운디드컨텍스트..
Domain Event 와 Command에 의해 관리되는 데이터, 명사로 표현한다. 일단 설게한 것을 기준으로 에그리게잇을 도출할 수 있다. 회원과 관련된 것은 회원의 에그리게이트로 도출할 수 있다. 전체적으로 붙여보면, 이렇다. 큰 맥락으로 묶을것은 묶는다 (사용자 포인트 어쩌고 저쩌고는 다 사용자 포인트로) 상태로 변경할것은 상태로 변경하고, 묶을것은 묶는다. 사실 여기서는 어떻게 묶을 것인지에 대한 개발자에 대한 생각에 따라서 달라 질수 있다. 일단 크게 보면 이렇다. 도서 대여도서 반납도서 (도서 상태) 회원 로그인 사용자 포인트 이렇게 하면, 어그리게이트 기준으로 객체를 뽑아볼수 있다, 그리고 머리속으로 그려진다. JPA 기준으로 개발을 많이 했어서, 해당 관련되서 생각을 하는게 그렇게 거부감은..