DevBoi

일단 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..

배치로 만들기는 오바스럽고, 간단하게 스케줄러가 필요할때, 스케줄러를 구현하면 편하다. 구현할일이 많지는 않아서, 기념적으로 정리한다. 나는 스케줄러로, 결제 처리와 빌링키 조회를 하기 위함이다. 1. 의존성 추가, 대부분 이미 추가한 의존성이라 그냥 사용가능하다고 봐도 무방하긴하다. implementation 'org.springframework.boot:spring-boot-starter-web' 2.메인 클래스 추가 @SpringBootApplication @EnableJpaAuditing @EnableScheduling public class InnabackendApplication { public static void main(String[] args) { SpringApplication.run..

바운디드 컨텍스트는 .. 그냥 뭐 여러가지 커맨드 액터 들을 얼마나 그룹핑 할것이냐...정도를 정하는 것이다. 대여 회원 도서 베스트 도서 로그인 이런식으로 바운디드 컨텍스트를 나눌수있고, 아까 정리했던 것들을 위의 분류 기준으로 나눠서 경계를 지정한다고 생각하면된다. 스케일 아웃이나, 여러가지 모듈을 나누는 기준이라고 생각하면 된다. 이런식으로 바운디드 컨텍스트가 나누어 지고 해당 바운드 컨텍스트 기준으로 보면 좀더 깔끔한 느낌을 받을수 있다. 정책이나, 모듈, 흐름에 대한걸 좀더 깔끔하게 보기 좋게 정리가 가능하다. 바운디드 컨텍스트도 핵심,일반,지원에 대한 종류가있다. 쿠팡으로 치면 배송이 핵심이고, 이 도메인이라고 치면, 대여에 대한 기능이 핵심 기능이 될 수 있어서, 대여에 대한 바운디드컨텍스트..

Domain Event 와 Command에 의해 관리되는 데이터, 명사로 표현한다. 일단 설게한 것을 기준으로 에그리게잇을 도출할 수 있다. 회원과 관련된 것은 회원의 에그리게이트로 도출할 수 있다. 전체적으로 붙여보면, 이렇다. 큰 맥락으로 묶을것은 묶는다 (사용자 포인트 어쩌고 저쩌고는 다 사용자 포인트로) 상태로 변경할것은 상태로 변경하고, 묶을것은 묶는다. 사실 여기서는 어떻게 묶을 것인지에 대한 개발자에 대한 생각에 따라서 달라 질수 있다. 일단 크게 보면 이렇다. 도서 대여도서 반납도서 (도서 상태) 회원 로그인 사용자 포인트 이렇게 하면, 어그리게이트 기준으로 객체를 뽑아볼수 있다, 그리고 머리속으로 그려진다. JPA 기준으로 개발을 많이 했어서, 해당 관련되서 생각을 하는게 그렇게 거부감은..

정책은 특정 이벤트가 발생됬을때 발생되어야 하는 커맨드의 기준이다. 무튼 정의 하면 아래와 같다. 도서가 대여되면, 사용자 포인트가 적립되는 걸 정책으로 연결해줄 수 있다. 도서가 대여되면 포인트가 적립된다 또한 도서의 상태가 동시에 변경이 된다. 그래서 뭐 이렇게 표현할 수 있다. 정리는 안했다 귀찮다 솔직히 나혼자 이런거 하는건,,,,그냥 알고만 있으면 되서 회사에서 시키면 정리하고 혼자서할때는 대충 하는 방법이나 테스트만해보도록하자....정리는...어려워..... 뭐 무튼 이런식으로 연체되면~ 대출되면~ 이런 정책들을 만들어서 표현하고 관리하면 된다. 개발자가...하는게 맞는거....지? 사실 잘모르겠다....ㅋㅋ 뭐 키클락이나 요즘은 여러 시스템을 외부에서 많이 도움을 받는다. 공통으로 써야한다고..

각각의 도메인 별로, 실제 행위를 하는 동사 즉 커맨드를 입력해서 메모를 한다. 액터는 말 그대로, 실제해당 행위를 하는 주체를 의미한다. 해당 주체를 액터라고 하고, 해당 액터를 표기함으로써 설계에 추가한다. 액터, 커맨드, 이벤트에 따른 색깔을 내 맘대로했더니 ㅋㅋ 조금 그러네;; 앞으로는 색깔부터 확실히 나누고 설계를 하도록하자 이렇게 커맨드랑 액터를 도출해볼수있다.

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

크게 상태가 있거나, 없는 상태로 만들수 있다. Stateless,Stateful 이 두가지 방식으로 개발을 할 수 있다. 아래의 과정을 한번 보자 주문접수자는 주문목록을 가지고 있고, 바리스타는 주문접수자가 넘겨준, 제작 목록에 남겨서 커피를 만들어서 별개의 병행으로 작업을 하고 이벤트로 진동벨에 전달을 한다. 이벤트 생성, 이벤트 대응하는 모듈을 분리하고 상호 독립적으로 동작하여, 병령처리를 촉진한다. 발신자,수신자를 장소와 시간에서 쉽게 분리가 가능하다. 또한 각 모듈간의 필요에 의해 스케일 아웃 등의 확장에용이하고 동기,비동기가 선택이 가능하다. 비동기로 선택했을때 관련 문제들이 발생할 수 있다. - 네트워크 장애, 중요한 순간 서버 장애, 이벤트 순서가 꼬임, 이벤트 중복 등 - 데이터 소실 처..