1. Kafka 란?

Kafka란? Event 기반의 Pub-Sub 연동을 가능하게 하는 메세지 큐 시스템. MSA 환경에서 많은 Micro Service간 결합을 풀어서 서비스간 영향도를 최소화시켜주는 역할을 합니다.

Kafka의 역할

1. 메세징 시스템
2. 모니터링 데이터 수집
3. 로그 수집
4. 시스템간 종속성 분리 등
   
   
   

2. Kafka 아키텍처

위 Kafka 아키텍처에 대해 간단한 설명을 덧붙이자면,

1. MSA 환경에서의 Micro Service는 각각 Producer와 Consumer의 역할을 수행
2. Producer는 Application 자체에서 정의된 규칙에 따라 이벤트가 발생
3. 이벤트가 발생했을 때, Producer는 Json 형태의 메세지를 Kafka 큐 시스템에 발송
4. 발송된 메세지를 구독한 Consumer 서버가 해당 메세지를 수신
   
   
   

이제 Kafka를 구성하는 요소들에 대해 하나씩 알아보겠습니다.

Topic

• Topic : Application으로부터 많은 메세지가 Kafka 서버를 통해 송수신이 되는데, 이러한 메세지들을 구분하기 위한 저장소? 데이터 스트림? 논리적 집합이라고 보면 됨 > application간 메세지는 kafka topic을 통해 전송됩니다.
  
  
  

• application의 이용량이 많아질수록 서버간 송수신되는 메세지가 많아지는데, 이러한 대용량 트래픽을 잘 처리하기 위해 토픽마다 파티션 기능을 활용할 수 있습니다.
  
  
  

Partition

• Parition : application에서 전송된 메세지를 선입선출 방식으로 적재하는 큐 형태의 저장소 -> producer로부터 전송받은 메세지를 consumer에서 선입선출 방식으로 메세지를 읽어와 처리합니다.
  
  
  

Partition 병렬처리

• 목적 : 토픽당 여러개의 Partition을 생성하여 많은 양의 메세지를 빠르게 처리할 수 있습니다. -> Partition을 늘리는 것은 가능하나 줄이는 것은 불가
  
  
  

• 병렬처리 특징

1. Partition당 Consumer의 메세지 처리 순서를 보장하기 위해 메세지별로 index를 부여하고, offset을 계산하여 다음 읽을 메세지를 Consumer에서 곧바로 확인할 수 있습니다.
2. Partition별 index 및 offset 계산은 독립적으로 수행 -> 동일 Partition에 메세지를 전송하면 Consumer에서의 처리순서를 보장할 수 있지만, 다른 Partition으로 메세지를 전송하면 순서를 보장할 수 없습니다.
3. 동일 key값이 부여된 메세지는 동일 partition에 적재 -> 메세지별로 동일 key값을 부여하는 방식으로 병렬처리 환경에서의 메세지 처리 순서를 보장할 수 있습니다.
   
   
   

Broker

• Broker : kafka 클러스터를 구성하는 각각의 kafka 서버
  
  
  

• 특징

1. 각각의 broker는 topic/partition을 가짐
2. 어떤 broker에 접속해도 전체 kafka cluster에 접속 가능
3. 3개부터 100개까지 늘어날 수 있음
   
   
   

Zookeeper

• Zookeeper : kafka broker를 관리 -> kafka 3.3 버전 이후 zookeeper는 deprecated될 예정
  
  
  

• 역할

1. partition의 리더 선출 (리더는 write/read, 서브는 read만 수행)
2. kafka 클러스터의 변경사항에 대한 알림
   
   
   

Topic Replication Factor

• Topic Replication Factor : topic별 partition 복제를 위한 설정 값 (ex. 값이 2일 경우, 파티션을 두개로 복제)
• 아래 사진은 Topic A의 파티션이 2개, Topic Replication Factor가 2일 때의 예시

• 특징

1. 특정 broker에 장애가 발생하여 해당 broker가 수용하는 partition이 제기능을 못할 경우, 다른 broker에 수용되어 있는 다른 복제본이 기능을 대신 수행 -> leader 파티션이 기능을 못할 경우, leader 역할을 복제본으로 변경
2. 토픽의 데이터가 3GB일 때, Replication Factor가 2이면 해당 토픽의 전체 용량은 6GB
   
   
   

3. Pub-Sub 연동

• MSA에서 Micro Service간 약결합 연동을 위해 비동기 메세징 방식의 pub-sub 연동을 활용할 수 있습니다. -> 비동기 메세징 방식을 위한 Data Stream으로 kafka가 활용됨

Producer

• Producer : 메세지를 생산하여 토픽으로 메세지를 보내는 application 혹은 서버
• 특정 토픽 및 파티션으로 메세지를 보낼 때, 메시지의 key 값을 설정한다면 특정 partition에 전송되도록 할 수 있습니다. -> key값이 없다면 라운드로빈 방식으로 파티션 지정하여 메세지 전송

• acks (메세지 전송 보장을 위한 producer 설정)

1. acks=0 : kafka의 응답을 기다리지 않음 (메세지 손실 가능성은 높지만 빠른 전송 필요)
2. acks=1 (default) : 리더 partition의 응답만 대기 (메세지 손실 가능성이 적고 적당한 속도의 전송 필요)
3. acks=all : 리더 및 ISR partition의 모든 응답 대기 (메세지 손실은 없지만 전송 속도 느림)
   
   
   

Consumer

• Consumer : 토픽에 저장된 메세지를 가져가는 application 혹은 서버

• Consumer Group : Consumer들의 집합, kafka 데이터를 처리하는 단위 -> Consumer Group과 Partition은 1대1 매칭만 가능 -> 동일 Consumer Group내 A Consumer가 A 파티션과 연동하고 있다면, 다른 B Consumer에서 해당 A 파티션은 연동 불가
  
  
  

• 특징

1. Consumer Group은 메시지를 가져간 후, offset을 해당 partition에 커밋
2. kafka는 내부적으로 별도 partition을 통해 커밋 정보 관리

4. Kafka Scaling

• kafka는 메세지 가용성 및 효율성을 위해 여려가지 Scaling 기능을 제공합니다.
  
  
  

Broker 스케일링

• Kafka 클러스터내 모든 Broker의 리소스 사용률이 현저하게 높을 경우, 새로운 Broker를 추가할 수 있습니다.
  
  
  

• 방법

1. 고유 ID를 부여한 새로운 Broker를 추가한 후 Zookeeper Ensemble에 연결합니다.

2. kafka-reassign-partitions 명령어로 Topic별 파티션을 리밸런싱 합니다.

Partition 스케일링

• Producer에서 파티션으로 메세지 저장에 병목이 발생할 경우, 해당 topic의 파티션을 증가시킬 수 있습니다.

• 주의사항

1. 파티션 수가 많을수록 파일 핸들러가 증가하므로 적절한 개수의 파티션 설정 필요
2. 증가만 되고 줄이는 방법은 없으므로 목표 처리량의 기준설정 필요
3. Consumer Group내의 Consumer 갯수와 동등한 파티션 갯수 설정 필요
   
   
   

• 방법

Consumer 스케일링

• 메세지 처리 지연(Message Lagging)이 발생할 경우, 메세지 처리를 수행하는 Consumer를 증가시킬 수 있습니다.
• Message Lag : Producer Pub 메세지와 Consumer Sub 메세지간 Offset 차이

• 스케일링 과정

1. Consumer 추가 (Scale-Out)
2. 각 Consumer Group당 코디네이터(Coordinator)가 Consumer 수 변경을 인지하게 되면 리밸런싱(소유관 이관) 작업을 진행 -> 파티션-Consumer 관계를 재배치

• 리밸런싱 : Consumer Group의 파티션 소유권을 재할당하는 작업 -> Producer의 메세지는 모든 파티션에 균등하게 배분
  
  
  

• 리밸런싱 조건

1. Consumer Group 코디네이터가 특정 Consumer의 장애로 판단할 경우 리밸런싱 진행 -> Consumer가 메세지를 폴링하거나 offset를 커밋할 때마다 해당 Group 코디네이터에 HeartBeat 메세지를 전송 -> 특정 시간동안 HeartBeat 메세지가 없는 Consumer를 장애로 판단
2. 특정 Consumer Group내 Consumer 수 변경
3. 특정 토픽의 Partition 수 증가
   
   
   

Replication Factor

• 리더 파티션의 장애를 대비하여 Replication Factor 값 설정을 통해 파티션을 복제할 수 있습니다.

• 방법

5. 병렬환경에서의 처리순서 보장을 위한 메세지 처리 과정

👉이전글(헥사고날 아키텍처와 MSA전환)에서 살펴본 것처럼 MSA 전환 시에는 API Gateway 모듈이 활용될 수 있습니다.

이러한 API Gateway는 MSA 전환 시, 레거시와 Micro Service간의 통합을 도와주는 역할 뿐만 아니라
Micro Service중 하나로서 다양한 역할을 수행합니다.

이번글에서는 API Gateway 개요와 다양한 역할, 구현 방법에 대해 소개하고
Rest API를 통한 요청-응답 시에 전체모듈로 장애확산을 방지하는 Circuit Breaker 기능에 대해서도 알아볼 것입니다.

API Gateway

API Gateway란? API Gateway는 백엔드 서비스 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 요청에 대한 라우팅 기능을 수행하고, 인증/인가 기능과 API 호출 로깅(logging) 기능 등 각 벡엔드 서버의 공통 기능을 수행하는 단일 모듈입니다. 이를 통해 뒷단의 각 백엔드 서버는 공통 기능을 별도로 구현하지 않아도 됩니다.

위 언급된 API Gateway의 많은 기능 중 본 글에서는 단일 진입점으로서의 라우팅 기능과 인증/인가 기능을 살펴볼 것입니다.

Routing

Routing 기능은 API Gateway의 대표적인 기능중 하나로서,
client에서 특정 Rule기반으로 API Gateway를 호출하기만 하면
해당 Rule에 맞게 뒷단의 백엔드 서버를 찾아서 요청을 전달해줍니다.

라우팅 Rule 유형은 다양하지만 일반적으로 Path 기반으로 라우팅하게 됩니다.
예를들어, http://{GATEWAY_IP}/order uri로 요청한다면 order micro service로 routing하고,
http://{GATEWAY_IP}/inventory uri로 요청한다면 inventory micro service로 요청을 routing하는 방식입니다.

MSA 환경에서 Gateway를 구현하는 방식은 다양합니다.
대표적으로 java언어 기반의 SpringCloud 프레임워크를 활용하는 방식이 있고,
kubernetes 인프라의 Ingress 모듈을 활용하는 방식이 있습니다.

SpringCloud vs Ingress

요약하자면,
SpringCloud는 Java 기반의 프레임워크이기 때문에 Java 기반의 application과 호환이 잘되고,
Java/SpringBoot의 편리한 기능을 모두 활용할 수 있기 때문에 Java 개발자에게 편리할 수 있습니다.
하지만, JVM을 지원하지 않은 다양한 스택의 application과 연동해야할 때, 다양한 기술스택 활용을 장려하는 MSA 환경 특성상 SpringCloud 활용이 부적절할 수 있습니다.

Kubernetes Ingress는 특정 언어 기반으로 구현해야하는 application이 아니고,
Kubernetes의 type중 하나로 실행되는 Gateway 템플릿이기 때문에 특정 환경에 종속되지 않아서
다양한 기술스택을 수용해야 하는 MSA 환경에 적합할 수 있습니다. (실제 Routing 기능을 수행할 nginx와 같은 app을 Ingress Controller로서 별도 설치 필요) 또한, programming 기반이 아닌 Menifest 파일 기반으로 routing rule을 설정할 수 있습니다.

요약만 보면 Ingress를 선택해야하는 것이 아닌가 생각이 들겠지만,
Spring기반으로 Filter를 커스터마이징할 수 있고, Path rewriting 등과 같은 기능을 활용할 수 있어
Gateway로 SpringCloud를 선택하는 경우도 있다고 합니다.

구현방법 (SpringCloud Gateway)

1. Gateway로 활용할 SpringBoot 프로젝트를 생성합니다.
   
   
   

2. 해당 프로젝트에 아래 dependency를 추가합니다

   <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
   </dependency>

   
   
   

3. 프로젝트 resources의 application.yml에 아래 routing rule을 설정합니다.

   spring:
   profiles: default
   cloud:
    gateway:
      routes:
        - id: monolith
          uri: http://localhost:8082
          predicates:
            - Path=/orders/**, 
        - id: inventory
          uri: http://localhost:8083
          predicates:
            - Path=/inventories/**, 
        - id: frontend
          uri: http://localhost:8080
          predicates:
            - Path=/**

   
   
   

위와 같이 설정을 완료하고 특정 호스트에 맞는 path를 Gateway url에 붙여 http 요청한다면,
해당 호스트로 요청이 routing 됩니다.
위 설정 기반으로 예를들면, http://{GATEWAY_IP}/orders에 요청했을 때 http://localhost:8082의 monolith 호스트로 routing 됩니다.

위 application.yml의 predicates 속성을 잘 활용한다면,
path 기반 rule 뿐만 아니라 다양한 요청 rule 기반으로 요청이 routing될 수 있도록 설정할 수 있습니다.

이전글에서 MSA개요와 Event Storming에 대해 다뤘고,
👉MSA개요
👉Event Storming
이번글부터는 MSA 구현방법을 하나씩 다뤄보겠습니다.

헥사고날 아키텍처 (Hexagonal Architecture)

MSA의 서비스 구현은 기본적으로 헥사고날 아키텍처를 준용합니다.

헥사고날 아키텍처란? 느슨하게 결합된 MSA 서비스 구현을 목표로
Micro Service 단위로 분리된 각 서비스마다 외부와의 연동을 위한 In/Out-Bound Adapter, DB접근을 위한 ORM을 구성하고,
서비스(도메인)별 언어활용을 통한 코드 작성 및 기술적 구현을 진행하는 아키텍처

위 사진과 같이 헥사고날 아키텍처를 준용하여 서비스를 구현한다면 MSA 목표인 독립성을 달성할 수 있을 것으로 기대합니다.

아래는 SpringBoot 기반의 헥사고날 아키텍처를 표현한 사진입니다.

Event Storming to SpringBoot

👉이전글에서 언급한 Event Storming을 활용하여 MSA 서비스를 설계한다면,
보다 쉽게 헥사고날 아키텍처를 준용하여 SpringBoot기반의 서비스를 설계할 수 있습니다.

아래는 Event Storming 스티커와 SpringBoot 모듈간 매핑 관계입니다.

1. Bounded Context : SpringBoot 서버 자체
2. Domain Event : 외부 서비스로의 연동전 Java 객체
3. Command : RestController, Repository
4. Aggregate : JPA or MyBatis or SpringCloud Stream Publisher
5. Policy : SpringCloud Stream Listener

MSA 전환

레거시에서 MSA로의 전환을 시작할 때, 일반적으로 아래 내용이 검토되어야 합니다.

그리고 Strangler 패턴을 적용하여 보다 안정적인 전환이 가능합니다.

Strangler 패턴이란? 레거시 모놀리스에서 Micro Service로 구현할 일부 모듈을 점진적으로 확대 분류하여 Micro Service로 구현함으로서
MSA 전환 시, 비즈니스 영향도를 최소화하는 패턴

해당 Strangler 패턴을 적용하기 위해서는 MSA로 분리된 서비스와 기존 모노리스를 어떻게 연동할 지에 대한 방법을 고민해야 합니다.
아래는 레거시와 MSA간 API 통합 방법입니다.

1. API Gateway : 단일 진입점, URL 기반의 라우팅 수행
2. Service Registry : MSA의 단일 진입점(API Gateway)을 구성하여 API Gateway가 MSA 클러스터 내의 인스턴스를 찾아갈 수 있도록 하는 방법
   
   
   

레거시와 MSA 서비스간의 단일 진입점인 API Gateway를 구성하여 URL 기반의 라우팅이 되도록 구성한다면,
MSA로의 점진적 전환을 위한 Strangler 패턴을 적용할 수 있습니다.

예를들어, Front 모듈에서 Back 모듈로 임의의 요청을 보낼 때의 url로 레거시 서비스와 MSA 서비스를 구분할 수 있다면,
API Gateway에서의 간단한 설정을 통해 url을 통해 레거시와 MSA를 구분한 라우팅이 가능하도록 설계할 수 있습니다. 이를 통해 레거시와 MSA를 통합할 수 있죠.

API Gateway와 Service Registry의 자세한 내용은 추후 별도 글로 다뤄보도록 하겠습니다.

Reference

• 사내 강의 (Developing Cloud Native Application) - 박용주 강사님

DDD (Domain-Driven Design)

DDD란?

DDD란? 소프트웨어 개발 전체 LifeCycle에서 도메인 중심의 사고를 장려하는 소프트웨어 개발 철학

도메인은 특정 분야의 비즈니스라고 볼 수도 있는데,
비즈니스 관점으로 소프트웨어 구조를 설계해보자는 패러다임(?)이라고 생각하면 쉬울 것 같습니다.

예시로 A호텔에서 IT회사인 B테크 회사에게 호텔 예약 플랫폼 개발 사업을 발주했다고 가정해보겠습니다.
기존대로라면 B테크 회사는 대중적으로 활용되었던 폭포수 모델을 활용하여 플랫폼 개발에 나설거에요.
요구사항 수집 -> 설계 -> 개발...
여기서 B테크는 고객의 요구사항을 데이터 및 시스템 중심으로 설계하여 개발을 진행합니다.

B테크는 고객의 요구사항을 데이터 및 시스템 관점으로 설계해야 하는 다소 까다로운 과정을 거치게 되고,
고객의 요구사항이 긴급하게 바뀌었을 때는 해당 과정을 다시 진행해야 하기 때문에 유연하게 대처하기 힘듭니다.

하지만 B테크가 DDD를 적용한다면?

1. 도메인(비즈니스) 지식 중심으로 해당 비즈니스 종사자와 설계를 같이 진행하기 때문에 설계과정을 보다 쉽게 진행할 수 있고,
2. 도메인 중심으로 코드 구조를 짜고 작성하기 때문에 요구사항이 변경되어도 유연하게 대처할 수 있습니다.
   
   

DDD 적용 규칙

위에서 언급한 DDD의 장점을 누리기 위해서는 비즈니스 종사자와 개발자가 코드 기반으로 원할한 소통이 보장되어야 합니다.
이를 위해 아래의 규칙이 준수되어야 하죠.

1. 유비쿼터스 언어 사용

: 비즈니스 종사자와 개발자가 모두 이해할 수 있는 네이밍을 활용해야 합니다. (ex. create_reservation -> make_reservation)

2. 다른 도메인간 언어 통일을 강요하지 않습니다.

: 다른 도메인간 언어 통일이 되었을 때, 오히려 혼란을 야기할 수 있습니다.

3. 코드 구조를 추상화하여 비즈니스 종사자가 쉽게 이해할 수 있도록 합니다.

• AS-IS

    public void createReservation(User user, Seat seat, LocalDateTime startTime, LocalDateTime endTime){
      Reservation reservation = new Reservation();
      reservation.setUserId(user.id);
      reservation.setSeatId(seat.id);
      reservation.setStartTime(startTime);
      reservtiion.setEndTime(endTime);
      this.reservationRepository.save(reservation);
     }

  
  
  

• TO-BE

    public void makeReservation(User user, Seat seat, LocalDateTime startTime, LocalDateTime endTime){
        this.reservationCommandService
            .makeReservation(user, seat, startTime, endTime);
    }

  
  
  

DDD in MSA

MSA개요는 👉MSA개요 글 참고

위와 같은 DDD 적용 규칙은 모놀리스 아키텍처보다 MSA에서 더 쉽게 적용될 수 있습니다.
모놀리스에서는 다른 도메인간 언어 통일이 필요하다는 등의 이유가 있기 때문이에요.

그렇기 때문에 DDD는 MSA에서 많이 활용되고 있는 방법론입니다.

DDD를 MSA에 적용한다고 했을 때,

1. 서비스를 얼마나 쪼갤지?
2. 쪼갠 도메인간 어떻게 연동할 것인지?
   에 대해 추가적으로 검토되어야 합니다.
   
   

서비스를 분해하는 방법

서비스를 얼마나 분해할 지에 대해서는 아래 기준을 고려하여 결정합니다.

1. 서비스 복잡도 : 서비스를 쪼갤수록 야기되는 서비스 구현 및 운영 복잡도
2. 비즈니스 차별성 : 서비스를 쪼갰을 때, 취할 수 있는 비즈니스 및 비용 관점의 이점

도메인간 연동하는 방법

도메인을 어떻게 연동할 지에 대해서는

1. 도메인간 연관성이 얼마나 높은지?
2. 도메인의 중요도가 어떻게 되는지?
   에 따라 달라집니다.
   
   

연관성 및 중요도가 높을 수록 아래 우선순위대로 연동방식을 고려해야 합니다.

1. shared DB : 도메인간 DB를 공유
2. req-res 구조의 동기식 연동 방식 : 타도메인의 연동에 대한 응답을 기다림
3. pub-sub 구조의 비동기식 연동 방식 : 타도메인의 연동에 대한 응답을 기다리지 않음
   
   

Event Storming

Event Storming 이란?

Event Storming이란? 시스템에서 발생하는 이벤트 중심으로 분석 및 설계하는 기법으로 MSA 기반의 도메인에 대한 빠른 이해를 도모

전통적 방식에서 진행하던 UML 및 ERD 설계 대신에 비즈니스 종사자와 함께 진행하는 과정으로 보면 됩니다.

Event Storming 방법

준비

• 참석자

1. PO(업무전문가, 비즈니스 종사자)
2. Front-End 개발자
3. Back-End 개발자
4. 퍼실리테이터 (Event Storming 전문가, Optional)
   
   
   

• 준비 도구

1. 벽이 넓은 공간 (Ex. 넓은 화이트보드 등)
2. 여러 색의 포스트잇
3. 검은색 보드마카
4. 파란색 테이프

진행

• 포스트잇 유형
  

  

  
  
  
  

• 방법 : 아래 언급된 순서에 맞게 포스트잇을 겹쳐 붙이는 방식, 연동의 경우는 선으로 연결, 분리된 도메인은 Bounded Context로서 분리 표시
  

  

  
  
  
  

• 순서

1. Event 발굴 : 비즈니스에서 발생할 수 있는 Event를 발굴
   • 오렌지색 포스트잇 활용
   • 동사의 과거형으로 네이밍 (유비쿼터스 언어, Ex. Account Created)
2. Command 도출 : 이벤트를 초래하는 페르소나(사용자or시스템)의 동작을 도출
   • 파란색 포스트잇 활용
   • 동사원형으로 네이밍 (유비쿼터스 언어, Ex. Create Account)
   • 초래되는 이벤트의 왼쪽에 겹쳐 붙임
   • 데이터에 변화를 일으킬 수 있는 동작 위주로 도출 (CRUD중 CUD case)
3. Actor 도출 : 특정 Command를 수행하는 주체를 결정
   • 노란색 포스트잇 활용
   • 명사로 네이밍 (유비쿼터스 언어, Ex. Customer)
   • 수행하는 Command의 왼쪽에 겹쳐 붙임
4. Policy 도출 : 특정 이벤트가 발생했을 때, 연쇄적으로 발생하는 동작을 도출
   • 분홍색 포스트잇 활용
   • Command와 동일하게 동사원형으로 네이밍 (유비쿼터스 언어, Ex. Send Email)
   • Command와 동일하게 초래되는 이벤트의 왼쪽에 겹쳐 붙임
   • 데이터에 변화를 일으킬 수 있는 동작 위주로 도출 (CRUD중 CUD case)
5. Aggregate 도출 : 같은 Entity를 사용하는 연관 도메인 이벤트들의 집합 도출
   • 노란색 포스트잇 활용
   • 명사로 네이밍 (유비쿼터스 언어, Ex. Account Mgmt)
   • Command와 Event 사이에 겹쳐 붙임 (Command와 Event가 겹쳐 붙어있는 경우, 분리하여 사이에 붙임)
   • 하나의 트랜잭션으로 동작이 필요할 경우, 하나의 Aggregate로 묶음
6. Bounded Context 도출 : 효율적으로 업무 용어를 사용할 수 있는 도메인별 범위로 분리
   • 분리방식 결정 (Domain별 or Transaction별 or Tech Stack별 등)
   • Bounded Context로 Micro Service를 구성한다면 효율적 커뮤니케이션이 가능함
7. Context Mapping : Aggregate간 연동방향 및 방식 결정
   • Event와 Command의 연결 : req-res 연동 방식
   • Event와 Policy의 연결 : pub-sub 연동 방식
     
     
     

• 기타

1. 특정 포스트잇에 대한 질문이 있는 경우, 보라색 포스트잇에 작성하여 문의의 포스트잇에 삐뚤게 붙임 -> 문의를 해결한 경우, 반듯이 고쳐 붙임
   
   
   

• 결과
  

  

  
  
  
  

Next

다음 글은 MSA 구현에 대해 살펴보겠습니다.

Reference

• 사내 강의 (Microservice Modeling) - 박용주 강사님
• DDD란 무엇인가 - 데이터 중심 개발과 도메인 중심 개발 : https://appleg1226.tistory.com/40