DevBoi

공식 문서를 참조해서, 정리했다. 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..

사내 도서대여시스템 이라고 가정하고 모델링 실습을 해보자 요구 사항은 아래와 같다. Miro라는 툴로 이벤트 스토밍을 진행할 수 있다. 온라인 이벤트스토밍 툴이다. Domain Event - 시스템에서 발생하는 중요한 이벤트 - 데이터가 아닌 비즈니스 프로세스에 집중 - 과거형 동사로 표현 Hot Spot - 질문,가정,경고,의견 수렴이 필요한 내용 - 병목 구간,자동화 필요한 수작업, 도메인지식이 없는 경우 - 완전히 정의되지 않은 영역, 해결해야 하는 문제 - 필요한 곳 어디에나 부착 가능 Command - 이벤트를 트리거 하는 명령 - 현재동사로 표현 Actor - Command를 동작하게 하는 사용자/역할 - 사람이나 역할의 이름을 명사로 표현 Policy - 다른 바운디드 컨텍스트에 영향을 주는..

axon framework는 axon server와 axon framework가 있다. axon framework 에서 이벤트 소싱이 발생될 때, axon-server가 아닌, 카프카나 외부 모듈을 사용할 수 있는데, 우선은 해당 axon-framework와, axon-sever를 통해서 진행해보자 axon framework의 아키텍처는 아래와 같다. 대게는 데이터를 변경하는 Command Event와, 조회용 Query에 대한 저장소가 분리 되어있다. 커맨드를 날리게 되면, 해당 Command Handling Component가 받아서, 처리를 한다. 처리 중에 외부 저장소에 영속이 필요한 경우 persist 작업을 거치고, 이러한 변화에 대한 이벤트를 이벤트 핸들링 Component가 받아 처리하는 ..

Aggregate 패턴은 도메인 모델 패턴이라는 거대한 개념에서, 좀더 세분화 된 모델링을 할 수 있다. 거대한 도메인 모델 패턴에서 적당히 쪼개야 하는데 Aggreagte개념으로 좀더 세분하게 쪼개는 것이다. 도메인 모델은 행위 + 자료구조를 통해 비지니스 로직을 구현한다. 도메인 모델은 POJO로 구성한다. Aggreate가 뭘까? 서비스에서는 행위를 기준으로 도메인을 호출하는데 이를 서비스 단위로 Aggregate단위로 묶는것이다. 몇가지 타입을 공통으로 모델링을 해서 사용하라고 가이드를 한다. Value object 란 뭘까? DTO와 비슷해 보이지만, DDD에서는 해당 valueobject는 DTO와 다르다. 개념적으로 완전한 하나를 표현하고, 고유의 식별자를 가지지않는다. 저 3가지 중에 Co..

aggregate - 데이터 요소 command - api 후보 전통적인 방법 인 트랜잭션 스크립트 패턴이 있다. 트랜잭션 단위로 데이터베이스를 작업하는 것이다. 절자 지향 스크립트로 구현하고, 데이터베이스 직접 접근도 가능하다. -> 트랜잭션 간 비즈니스 로직이 중복 되기 쉽다, 추후 유지보수가 어려워진다. 이런 코드의 패턴은 무조건 거부는 아니고 유지보수하는데 불리하게 발전될 가능성이 높다. 왜냐면 최근 방문일시를 update하고 방문을 insert하는 것은 결국 추후에 if,else로 길게 발전될 가능성도 높고 각각의 메소드가 다른곳에서 중복적으로 사용될 가능성도 높기 떄문이다. 또한 만약에 코드에 sql 문이 있다면, DB의 기술에 대한 종속성이 존재해 버린다. 따라서 이런 코드는핵심 도메인 코드..

각기 다른 도메인들은 독립적으로 발전 할 수도 있지만, 상호작용해야한다. 각 접점이 존재한다. 이를 contract라고 한다. - 협력형 패턴 그룹 - 사용자,제공자 그룹 - 분리형 노선 결재자와 수취자에 대한 개념을 모델링을 했다고 하면, 각각 다른 도메인에 있어, 다른 위치에 있지만, 의미는 같다. 이를 같은 의미인지 통역해주는 과정이 컨텍스트 매핑이다. * 협력형 패턴 * 공유 영역 공유 영역이라고 하면, 라이브러리 영역을 공통으로 포함을 해서 배포를 각각 A,B를 한다. 마이크로 서비스할때는 공유 영역을 최소로 하는것이 중요하다. 대부분의 패턴은 공급자,소비자 패턴을 쓴다고 한다. 정보를 받을때 공급자 입장에서는 upstream, 소비자 입장에서는 downstream이라고한다. 상류의 모델에서, ..

마이크로 서비스를 식별할때 대중적으로 쓰이는 방법이다. 비지니스 도메인 : 기업의 주요활동영역, 회사가 제공하는 서비스 (sub domain) 하위 도메인: 비즈니스 활동의 세분화된 영역, 제공하는 서비스 단위 쉽게 얘기하면, 도메인과 서브 도메인으로 분류할 수 있다. 하위 도메인의 개념 하위 도메인은 도메인을 표현하는 영역이다. * 핵심 -회사가 경쟁업체와 다르게 수행하고 있는 것 -복잡성 높지만 BIz경쟁력 제공 * 일반 - 모든회사가 같은 방식으로 수행하는 비지니스 활동 - 복잡하고 구현하기 어려우나, 경쟁력을 제공하지는 않음, 알려진 영역 - 인증,권한 * 지원 - 회사 비지니스 지원활동 - 기능간단,어떠한 경쟁우위 제공하지 않음 - CRUD, ETL 유비쿼터스 언어 도메인 주도 설계에서는 도메인..