DevBoi

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

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

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

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

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