DevBoi

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

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

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

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

* 명령 조회 책임 분리 * 커맨드 실행 모델 : 비즈니스 로직 구현, 강력한 일관성 * 읽기 모델 : 인메모리 캐시, 일반 파일, materialized view, 읽기 전용 * 동기화 필요 : 동기식, 비 동기식 * 확장, 읽기 성능,다양한 저장소 커맨드에서 들어온 저장소와, 읽기에서 들어간 저장소가 다른것이 좋은데 이 두개 다른 저장소에 대한 일관성을 유지해주는 것이 좋다. 따라서 쓰기 데이터 저장소와 읽기 데이터 저장소를 분리하지만, 해당 데이터에 대한 일관성은 유지해주는 것이 좋다. 데이터 동기화는 동기식이던, 비동기식이던 필요하다. 두개는 비동기식으로는 메시지 큐를 이용해도되고, CDC를 이용해서 동기식으로 해도된다. 일단 CQRS의 가장 큰 이유는 커맨드에 따른 일관적인 데이터 쓰기 이고 읽..

레이어드아키텍처의 개선방향으로 아키텍처에 대한게 두가지 정도있다. 비즈니스 로직은 내부영역에 놓고, 외부영역에 즉 가변적인 영역을 외부에 놓는다. 클린아키텍처는 아래와 같다. 서비스는 유스케이스에 해당 된다. 원리는 헥사고날과 비슷하다. 가변적인 영역을 외부에 놓고, 비즈니스 로직을 내부에 놓는다. 외부 서비스에서 Aggregate를 호출하고, 혹은 프록시나 이벤트를 사용한다. 서비스는 필요시에 비즈니스 도메인인 Aggregate를 호출하고 이는 엔티티나 VO를 호출하게된다.

마이크로서비스 내부 구조 정의는 어떻게 해야할까 전술적 패턴은 비즈니스 로직을 모델링하고, 구현하는 다양한 방법이다. 가장 고전적인 아키텍처는 3계층으로 구현하는 것이다. 프리젠테이션 레이어, 비지니스 로직 레이어, 데이터 엑세스 레이어 이렇게 3가지 레이어가 존재한다. 레이어드 아키텍처 근접 레이어만 접근 가능하다 Top-down 아래로 의존적이고 순방향이다. 흔히아는 MVC컨트롤러는 프리젠테이션 계층에 속한다. 가장 중요한 계층은 비즈로직 계층이다. 레이어드 아키텍처 다양한 변종이 존재한다. 레이어드 아키텍처는 비즈니스 로직과 데이터 접근 계층간의 의존성이 있다. 비즈 로직 구현이 트랜잭션 스크립트, 엑티브 레코드인 경우 적합한 아키텍처이다. 그렇지만, 결국 데이터 처리에 비지니스 로직이 점점 몰리게..

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

개체 모델을 만들고, 행위를 그 안에서 선언 서비스에서는 해당 행위에 대한 선언으로 로직을 처리한다. 액티브 레코드 패턴은 행위가 getter,setter,save()만 있는 것을 의미한다. 바람직한 것은 행위가 엔티티안에 들어가서 비즈니스 로직에 대한 처리를 담당해주는 것이 좋다. User라는 엔티티가 있다고 하면 주소변환에 대한 메소드 행위를 Member entity안에 넣는 것이다. 예를 들면 @Getter @Setter class Member{ private String city; private String dong; public void 주소바꾸기(String city,String dong){ this.setCity(city); this.setDong(dong); } } 뭐 이런식으로 진행이 되..