1. 모놀리틱 아키텍처 vs 마이크로서비스 아키텍처

모놀리틱 아키텍처
모든 기능들을 하나로 묶어서 관리하는 아키텍처
→ 구현이 간단하지만, 실용성 낮음

마이크로 아키텍처
작은 서비스들의 집합체로 관리하는 아키텍처
→ 구현이 어렵지만, 실용성 높음

모놀리틱 아키텍처에서 마이크로 아키텍처로 분리/발전해나가는 것이 DevOps의 핵심!

1.1 장단점

1. 모놀리틱 아키텍처의 장점 (마이크로 아키텍처의 단점)
   • 빠르고 간단하게 서비스를 만들 수 있음 (빠르게 시장성 검증이 가능)
   • 유지보수 용이
   • End-to-End 테스트 용이
   • 모니터링 용이
   • 각 기능별 독립적인 언어 사용이 가능
2. 모놀리틱 아키텍처의 단점 (마이크로 아키텍처의 장점)
   • 작은 수정사항에 있어 유동성이 부족 (전체를 다시 빌드하고 배포)
   • 유지보수 어려움
   • End-to-End 테스트 어려움
   • 모니터링 어려움
   • 각 기능별 독립적인 언어 사용이 불가능
   • 일부의 오류가 전체에 영향을 미침
   • 구동시간이 늘어남

2. 소규모 아키텍트

2.1 도메인 주도 설계 (Domain Driven Design)

2.1.1 기존 프로세스

1. 역할
   1. 기획자
      • 사업 기획
      • 서비스 기획
      • 요구사항 정의
   2. 마케터
      • 사업 기획
      • 지표 관리
      • 아이디어 제안
   3. 개발자
      • 설계
      • 구현
      • 유지보수
   4. 디자이너
      • 페이지 디자인
      • 배너 디자인
   5. PM
      • 기획자, 마케터, 개발자, 디자이너 조율
      • 일정관리
2. 프로세스
   • 시장 조사 → 서비스 기획 → 베타서비스 개발 → 마케팅(소규모) → 수정 기획 → 서비스 개발 → 마케팅
   • 요구사항 분석 → 설계 → 구현
3. 문제점
   • 기획과 개발의 불일치 발생 (소트프웨어 개발과 도메인, 모델과의 불일치)
     도메인 - (추상화) -> 모델 - (실체화) -> 소프트웨어
4. 해결방안
   • 보편언어(ubiquituous language)를 사용
     도메인에 대한 어휘를 이해관계자(기획자, 개발자, 분석가 등)들이 공통적으로 이해할 수 있도록 정의
   • 모델 주도 설계
     • 도메인 분석과 설계의 간극을 최소화
     • 분석/설계/구현의 모든 단계를 관통하는 하나의 모델을 유지
     • 모델 = 코드

2.1.2 도메인 주도 설계

소프트웨어가 복잡한 이유는 도메인이 복잡하기 때문

• 도메인 전문가(기획자)와 개발자가 어떻게 협업할 것인가가 중요
• 보편언어, 모델 주도 디자인

1. DDD의 2가지 종류
   1. 전략적 설계
      • 비즈니스의 상황(context)에 맞게 설계
      • 모든 context를 이벤트 스토밍을 통해 공유
      • 각 context를 grouping (bounded context)
      • 컨텍스트 매핑을 통해 bounded context 간의 관계를 정의
      • 전략적 설계의 결과물: 도메인 모델(서비스를 추상화한 설계도, 분리 & 연결)
   2. 전술적 설계
      • 더 상세한 부분(bounded context 내부) 모델링
      • Model driven design
      • Aggregate pattern
      • 계층형 아키텍처를 통한 도메인 모델 분리
      • 도메인 이벤트를 통해 도메인을 보다 명확히 모델링

2.1.3 이벤트 스토밍

1. Domain Event 정의
   • Event: Actor가 Action을 하여 발생한 결과
   • 각자 생각나는 Event를 적고 더 이상 생각이 안 날때까지 붙임
   • 서로 상이하면서 중복된 것을 없애거나 합침
   • 이벤트가 발생하는 시간 순서대로 붙임. 동시 수행되는 이벤트는 수직으로 붙임
   • 비즈니스 용어로 무슨 일이 발생했는지를 적어야함
2. 프로세스 그룹핑
   각 이벤트를 그룹핑
3. Command 정의
   • Command: 사용자의 행위
   • 각 event에 대하여 해당 event를 발생시키는 command가 무엇인지 생각하고 왼쪽에 붙임. (command 하나에 여러 개의 event 할당 가능)
4. Trigger 정의
   • Command를 수행하는 Actor를 정의하고 Command의 좌하단에 겹쳐서 붙임
   • Event 발생과 관련된 외부 시스템이 있다면 Event의 우상단에 겹쳐서 붙임
5. Aggregate 정의
   • Command 수행을 위해 CRUD해야하는 데이터 객체 정의
   • Command를 수행해서 Event를 발생시키려면 어떤 데이터가 필요한지 command와 event 사이의 위에 붙임
6. Bounded context 정의
7. Context Map 작성