MSA 설계

데이터 생성/변경은 소유 도메인이 책임진다

주요 구성

boundedcontext,event,command,aggregate,policy,readmodel

• 바운디드컨텍스트: 보통도베인인거같음
• command
  • 사용자나 시스템의 명령을 표현하는 메세지
  • 외부랑 소통하는 부분(rest api)
  • 누가 : actor
• event
  • cud 에 해당하는 시스템에서 발생한 사실
  • kafka가 멀까
  • 이미 완료된작업을 기술함
  • ~~ ed
  • 나중에 클래스가 됨
• aggregate
  • 이동되는 데이터의 형식(Entity)이 정의
  • DB랑 연결되서 crud가 일어날 수 있음
  • 나중에 클래스가됨
• policy
  • 특정 이벤트 발생시 시스템이 자동으로 시행해야하는 규칙or 비지니스 로직
  • 나중에 함수가됨
• 일반적인 흐름
  • actor > command > event > aggregate > policy

aggregate

관련 아키텍처

헥사고날 아키텍처

애플리케이션의 핵심 로직(비즈니스 로직)을 외부 환경(UI, DB, 메시징 등)과 분리하여 설계하는 구조

• 내부 핵심 로직은 ‘포트(Port)’를 통해 외부와 연결
• 외부 시스템은 ‘어댑터(Adapter)’를 통해 이 포트를 사용
  • inbound : 이벤트 송수신
  • outbound : db 접근
• 장점
  • 테스트가 쉬움
  • 외부 환경(DB나 API 등)이 바뀌더라도 핵심 로직을 그대로 유지가능
• 사견임 ,, 내느낌엔 리눅스가 레이어드아키텍처랑 비슷하다고생각이됨
  • 레이어를 나눠서 통로를 정해놓은느낌

CQRS

• 읽는작업과 변경하는작업을 분리해서 처리
• 이벤트가그러잔슴!! 이벤트는 read는 생각안한다구!!
• command : cud
• quary : read (여기선 읽는작업을 쿼리라고함)

관련 문서

• msa 개념
• MSA 장단점
• msa전체적인 구조
• kafka가 멀까