KimYHG

필요하다면 쓰면 좋은 디자인인 것 같다.

다만, 이를 실행할 수 있는 조건이 높고 복잡하다.

비즈니스적으로 모든 상황에 적합한 것은 없다는 것이다.

상황에 따라 최적의 방법을 찾는 것이 중요하다.

선택의 폭을 넓힐 수 있었다.

적합한 상황을 갖게 된다면 적용하고 싶다.

DDD 목표

• 복잡한 소프트웨어 시스템을 개발할 때 도메인의 지식과 비즈니스 로직에 초점을 맞추는 것
  -> 도메인 설계부터 개발까지 전 과정에서 사용하는 용어를 통일(유비쿼터스 언어)시켜
      소프트웨어 코드의 구조와 언어를 비즈니스 도메인의 용어와 일치시킴
  => 소프트웨어가 비즈니스의 핵심 문제를 해결하는데 집
    

DDD 장점

• 복잡한 비즈니스 로직을 효과적으로 처리
• 도메인 전문가와 개발자 간의 원활한 커뮤니케이션 지원
• 유지보수성과 확장성이 높은 코드를 작성 가능
• 비즈니스 로직과 기술적인 구현을 분리 => 코드의 가독성과 재사용성을 높임

DDD 도전과제

• 초기 학습 곡선이 높고 팀 전체의 이해와 협력이 필요
• 작은 프로젝트나 간단한 도메인에서는 오히려 과도한 복잡성을 초래
• 도메인 전문가(현업)와 긴밀하게 협력할 수 있는 환경 필수
• 시간이 많이 걸림 - 코드를 짜기 전에 알아야 할 것이 많음

DDD와 다른 개발 패턴의 조합

• MSA, 이벤트 소싱, CQRS, Hexagonal Architecture, Event-Driven와 같은 패턴과 함께 할 때 강력한 효과를 발휘

DDD 설계

• Strategic Design(전략적 설계, 개념 설계) + Tactical Design(전술적 설계, 구체적 설계)
• 도메인 분석 -> 모델 설계 -> 코드 구현 -> 도메인 경계 정
• Strategic Design - Event storming으로 진행
  1. Domain Event 정의
  2. 업무 흐름으로 보완
  3. 프로세스로 그룹핑
  4. Domain Event를 발생시키는 명령어 매핑
  5. Actor와 External System / Policy, Rule 추가 (Trigger 정의)
  6. Aggregate 추가
  7. Bounded Context 그룹핑
  8. Context Map 추가
• Strategic Design 산출물
  • Domain Model, Domain 분해도, Context Map
  • Domain 분해도 : 최상위 도메인을 서브도메인으로 나누고 각 서브도메인의 타입을 Core, Support, Generic으로 나눈 것
• Tatical Design - 개발을 위한 구체적인 설계 - Layered 설계 적용
  • 데이터 중심 설계에서 벗어나는 것
  • 도메인, 서브도메인, 바운디드 컨텍스트를 구분하고 정의
  • 이를 바탕으로 Aggregate, Entity, Value Object, Repository 등을 구현

• Tatical Design 산출물
  • User story(주체가 사람인 요구사항명세서)
  • Usercase diagram
  • Sequence diagram
  • Class diagram
  • Data Model
  • Storyboard(화면설계서)
  • API 설계서
  • 메시지 설계서
• 구체적 설계 자세히(Layered 설계 적용) - 패키지 구조 (DDD 적용)
  • application에 들어가는 dto와 service는 실질적으로 business 로직을 그리는데 사용
    (실질적 로직이 사용하는지 아닌지는 의견이 나뉨)
    @service와 이 계층에서 사용할 dto와 responseDTO가 포함됨
  • domain에 model, repository, service가 들어가고
    model에는 정의된 도메인의 루트도메인과 서브도메인을 모델화한 Entity와
      VO 등이 들어가고 루트엔티티가 하나의 도메인 내에 있는 다른 서브엔티티를 수정하도록 구성한다
    repository에는 설계서인 interface로 구현한 repository가 들어간다
    service에는 domain별로 나눌 수 없는 service구현이 들어가기도 하고 구체적인 코드를 가지기도 한다
  • infrastructure에는 repository, configuration, messaging 과 같이 외부와 연결된 부분, 설정 등
      실질적으로 연결하는 부분과 계층들을 지원하는 부분이 포함된다.
    repository는 실질적인 코드가 들어가서 JPARepository나 구현코드가 담긴 클래스가 배치된다
  • presentation에는 ui 혹은 api와 관련된 controller와 requestDTO가 들어간다.
    requestDTO가 여기에 들어가는 이유는 외부와 정한 값들에 대해서만 사용되어서 application에서 직접적으로 사용되거나 만들어지지 않는 것이어서 여기에 들어간다.

DDD 주요 용어

• Domain(도메인) : 소프트웨어가 해결하려는 특정 문제 영역 / 유사한 업무의 집합
• Ubiquitous Language(유비쿼터스 언어) : 공유하는 공통 언어 / 코드, 문서 등에서 일관되게 사용
• bounded context(바운디드 컨텍스트) : 도메인을 논리적으로 나누는 경계 / 비즈니스 목적별로 난 Context
  context : 도메인의 사용자, 프로세스, 정책 등을 의미
• Entity(엔티티) : 고유 식별자를 가진 객체
  VO(Value Object) : 고유 식별자가 없는 불변 객체
• Aggregate(애그리거트) : 연관된 엔티티와 VO의 집합 / 특정 비즈니스 규칙을 중심으로 구성
• Reoisutiry(리포지터리) : 애그리거트를 저장하고 검색하는데 사용되는 추상화 계층
• Domain Service(도메인 서비스) : 엔티티나 VO가 자체적으로 수행할 수 없는 비즈니스 로직을 처리
• Factory(팩토리) : 객체 생성 로직을 캡슐화하여 복잡한 객체나 애그리거트의 생성을 책임진다.

수정필요

RESTful API

• REST 아키텍처 스타일을 따르는 API
• 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스

API (Application Programming Interface)

• 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의
• 정보를 교환가능 하도록 하는 것

REST(Representational State Transfer)

• 클라이언트와 서버 간의 통신을 설계하는 원칙과 규칙의 집합
• 주로 HTTP 프로토콜을 기반으로 한다.
• 데이터와 상태코드 등을 규칙에 맞게 전송
• API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처
• 표현 : 형식이 지정된 리소스
• HTTP URI를 통해 리소스를 명시하고,
  HTTP Method를 통해 해당 리소스에 대한 CRUD Operation을 적용하는 것을 의미
• 리소스 기반의 구조 설계의 중심에 리소스가 있고 HTTP Method를 통해 리소스를 처리하도록 설계된 아키텍처

REST의 주요원칙

1. 클라이언트-서버 구조(Client-Server Architecture)
   • 클라이언트와 서버는 서로 독립적으로 개발될 수 있다.
   • 클라이언트는 사용자 인터페이스를 담당하고
     서버는 데이터와 비즈니스 로직을 관리한다.
2. 무상태(Stateless)
   • 각 요청은 완전하고 독립적이다 - 각 요청은 서로에게 영향을 안 준
   • 서버는 이전 요청의 상태를 저장하지 않는다.
   • 요청에는 필요한 모든 정보를 포함한다.
3. 캐시 가능(Cacheable)
   • 응답은 캐시 가능해야 하며, 이를 통해 성능과 확장성을 향상시킬 수 있다.
   • 캐싱 가능한 리소스는 적절한 HTTP 헤더를 통해 정의된다.
   • 캐싱 : 서버 응답 시간을 개선하기 이ㅜ해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로레
4. 계층화된 시스템(Layered System)
   • 클라이언트는 중간 서버(프록시, 로드 밸런서 등)가 서버에 대한 응답을 
     수정하더라도 이를 인식하지 못한다.
   • 계층 구조를 통해 확장성과 보안을 개선할 수 있다.
5. 통합된 인터페이스(Uniform Interface)
   • 리소스는 고유한 URI로 식별된다
   • HTTP표준 메서드(GET, POST, PUT, DELETE 등)를 사용하여 리소스를 처리한다
   • API 설계는 명확하고 일관성이 있어야 한다.
   • 표준 형식으로 정보를 전송한다.
6. 온디맨드 코드
   • 필요에 따라 클라이언트로 실행 가능한 코드를 전송할 수 있다.
   • 클라이언트 기능을 일시적으로 확장할 수 있다.
   • 서버로부터 스크립트를 받아서 클라이언트에서 실행한다

RESTful API의 주요 구성 요소

• 클라이언트 요청 - 고유 리소스 식별자, 메서드, HTTP 헤더
• 서버 응답 - 상태 표시줄, 메시지 본몬, 헤더
• 리소스(Resources)
  • 리소스는 데이터를 나타내며, URL을 통해 고유하게 식별된다.
• 고유 리소스 식별자
  • 서버는 일반적으로 URI을 사용하여 리소스 식별을 수행
• HTTP 메서드
  • RESTful API는 CRUD 작업을 HTTP(Hypertext Transfer Protocol) 메서드로 매핑한다
    GET, POST, PUT, PATCH, DELETE
• 표현 (Representation)
  • 리소스는 JSON, XML 등 다양한 포맷으로 표현될 수 있다. - 데이터를 인식하는 형태
  • JSON이 가장 널리 사용된다
• 상태코드(HTTP Status Codes)
  • 서버 응답은 표준 HTTP 상태 코드를 포함한다.
    200 : 성공
    201 : 리소스 생성 성공
    400 : 잘못된 요청
    404 : 리소스 없음
    500 : 서버 오류
• HTTP 헤더
  • 요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터
      요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공
  • 응답 헤더는 응답에 대한 추가 컨텍스트를 제공, 서버, 인코딩, 날짜 및 콘텐츠 유형과 같은 정보를 포함
  • 데이터, 파라미터(경로 파라미터, 쿼리 파라미터, 쿠키 파라미터)
• 상태표시줄

RESTful API 인증 방법

• 응답을 보내기 전에 먼저 요청을 인증해야 함
• 인증 : 신원을 확인하는 프로세스
• 일반적인 인증 방법 4가지
  • HTTP 인증
    • 1. 기본 인증 - 요청 헤더에 사용자 이름과 암호를 넣어 전송 / 사용자 이름과 암호를 base64로 인코딩하여 전송
    • 2. 전달자(bearer) 인증 - 요청 헤더에 토큰을 넣어 전송 / 토큰 : 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열
  • 3. API 키 - 서버가 최초 클라이언트에 고유값을 할당한 것
        API 키는 클라이언트가 관리한다
        이 API키를 요청시에 전달해서 리소스에 액세스한다
        네트워크 도난에 취약
  • 4. OAuth - 암호와 토큰을 결합하는 방법
        서버는 먼저 암호를 요청한 다음 추가 토큰을 요청 -> 권한 부여 프로세스를 완료
        특정 범위와 수명으로 언제든지 토큰을 확인할 수 있다.

RESTful API의 장점

• 간결성 : 설계가 단순하고 이해하기 쉽다
• 확장성 : 계층화된 아키텍처와 캐싱을 통해 확장이 용이하다.
• 유연성 : 다양한 클라이언트에서 사용할 수 있다.(브라우저, 모바일 앱 등), 
      클라이언트-서버를 분리하여 각 부분이 돍립적으로 발전할 수 있도록 
• 표준성 : HTTP 프로토콜의 표준을 따른다.

MSA : Microservices Architecture

1. MSA

• 시스템(하나의 애플리케이션)을
  여러 개의 독립적인 작은 서비스로 나누어
  관리(개발, 배포, 유지 보수)하는 
  소프트웨어 아키텍처
• 각 서비스는 특정 비즈니스 기능을 수행 => 도메인 주도 설계(DDD)에 많은 영향을 받음
  (도메인 : 사용자가 요구하는 문제 분야 내에서의 상황이나 내용)

2. 특징

• 독립적인 배포 가능성 : 각 서비스는 독립적으로 배포하고 업데이트 및 스케일링 가능
• 서비스마다 작은 팀이 독립적으로 개발, 관리 가능
• 각 서비스는 적절한 기술 스택을 자유롭게 선택 가능
• 서비스 간 통신 - API( REST, gRPC, 메시지 큐 등)로 통신

3. 모놀로틱 아키텍처와의 비교

4. MSA 주요 구성 요소

• 서비스
• API 게이트웨이
• 서비스 디스커버리
• 데이터베이스
• 통신 프로토콜

5. MSA가 적합한 경우 

• 빠른 변화와 확장이 필요한 대규모 시스템
• 팀이 여러 독립적인 기능을 동시에 개발 및 배포해야 하는 경우
• 다양한 기술 스택을 사용하거나 여러 시스템 간의 통합이 필요한 경우

6. 주의할 점

• 하나의 서비스를 너무 잘게 쪼개지 않기 - 하나의 서비사 ~ 하나의 도메인 담당
• 트랜잭션을 처리 => 분산 트랜잭션 등을 고려해야 함
• 데이터 분산 관리와 일관성(CQRS, 이벤트 소싱)

5. 알아야 할 도구

• 컨테이너화 - Docker, Kubernetes
• 서비스 디스커버리 - Eureka, Consul, Zookeeper
• API 게이트웨이 - Spring Cloud Gateway, Kong, NGINX
• 메시징 시스템(메시지 브로커) - RabbitMQ, Apache Kafka, ActiveMQ
• 모니터링 및 로깅 - Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana)
• 배포 도구 - Jenkins, GitLab CI/CD, ArgoCD

6. 활용 사례

• 대규모 전자상거래 시스템( ex> Amazon, eBay )
• 스트리밍 서비스( ex> Netflix )
• 금융 거래 시스템

7. Java군 적용하기

https://kimyhg.tistory.com/41

<아키텍처>

 - 시스템 구성과 동작원리 그리고 시스템의 구성환경 등을 설명하는 설계도

 - 최적화

 - 총체적이고 종합적이고 상세하게 개발을 준비하는 것

<시스템 아키텍처>

 - 하드웨어와 소프트웨어 아키텍처를 기반으로

    시스템이

    서비스를 제공

    하기 위한 아키텍처

 - 스토리지, 서버, 네트워크의 요소들을

    어떻게 배치키는지에 따라

    시스템 아키텍처 종류가 나뉜다.

 - 웹 애플리케이션(서비스)이 돌아가기 위해서는 여러 아키텍처가 통신을 한다.

 - 시스템의 구조와 성능 및 신뢰도 등에 영향을 미치는 중요한 요소

 - 아키텍처를 이해하면 코드를 더욱 체계적으로 작성할 수 있고, 장기적으로는 시스템 유지 보수와 확장을 용이하게 할 수 있다.

 - 시스템의 전체적인 구조를 정의하고 각 요소 간의 관계와 설계 지침을 세우는 데 초점을 둔다.

<소프트웨어 아키텍처 원칙>

 - 소프트웨어 설계 및 구현 과정에서 발생하는 복잡성을 관리하고, 유지 보수와 확장을 용이하게 해주는 지침

 - 관심사 분리, 모듈화 , 추상화, 캡슐화 등이 있음

    -- 관심사 분리(Separation of Concerns) :

      소프트웨어 시스템을 독립된 부분으로 나누어 각 부분이 특정 관심사에만 집중하도록 하는 설계 원칙

      ex> UI 로직과 비즈니스 로직을 분리, 환경 설정과 애플리케이션 코드를 분리..

    -- 모듈화(Modularity) : 

      시스템을 여러 모듀로 분할하고, 각 모듈이 특정 기능을 담당하도록 하는 방식

      느슨한 결합(Coupling)과 높은 응집도(Cohesion) : 모듈 간의 결합도 낮추고 각 모듈 내부의 응집도 높이

      ex> 전자상거래 시스템 => 제품 관리, 주문 처리, 결제 등으로 모듈화

      -- 추상화와 캡슐

<아키텍처 선택시 중요한 고려 사항>

 - 시스템의 규모와 복잡도

 - 팀의 기술 역량

 - 예산과 리소스

 - 변경 가능성

 - 배포와 운영의 편의

First. 

 - 모노리틱 아키텍처와 RESTful API 설계

 - 클린 아키텍처 익히기

Second.

 - 마이크로서비스, 이벤트 기반 아키텍처, 서버리스 아키텍처

 - AWS, Kafka, Docker 익히기

Third.

 - CQRS, 분산 아키텍처, 서비스  메시 익히기

 - 성능 최적화와 확장성 설계

1. 모노리틱 아키텍(Monolithic Architecture)

  - 애플리케이션을 하나의 단일 코드베이스로 개발, 배포하는 소프트웨어 설계 방식

  - 애플리케이션의 모든 구성 요소가 하나의 통합된 코드베이스와 실행 환경에서 함께 작동

  - 많은 레거시 시스템이 이 구조로 설계

  - 계층적 설계( Presesntation, Business, Data Access Layers)

  - 특징 :

    -- 단일 코드베이스 구성

    -- 단일 배포 단위(애플리케이션을 실행하기 위해 하나의 실행 파일만 있으면 됨)

    -- 강한 결합(모듈들이 서로 밀접하게 연결)

    -- 단순한 개발 초기(상대적으로 접근 쉬움, 초기 프로토타입 개발시 유용함)

  - 장점:

    -- 쉬운 개발 및 디버깅

    -- 일관된 성능

    -- 간단한 배포 : 애플리케이션 한 번에 빌드하고 배포

  - 단점:

    -- 확장성 부족 : 특정 기능만 확장하기 어려움

    -- 유지 보수의 어려움 : 변경 사항이 전체 시스템에 영향을 미칠 가능성이 있음

    -- 배포의 위험성 : 재배포시 전체 시스템 중단해야 함

    -- 기술 스택 제한 : 일부에서 더 적합한 기술만 변경 불가

  - 알아야 할 도구 : 서버 애플리케이션 프레임워크(Spring Boot, Django, Express.js)

2. RESTful API 아키텍처 & GraphQL

  - REST는 표준화된 설계 방식, GraphQL은 유연한 데이터 쿼리 제공

  - REST API 설계 원칙 (HTTP Method, 상태 코드 , HATEOAS)

  - GraphQL 스키마 설계 및 Resolver 구현

  - API 버전 관리와 보안 (OAuth2, JWT)

  - 알아야 할 도구

    --  API Gateway (Kong, AWS API Gateway)

    -- REST 및 GraphQL 서버 구현 라이브러리 ( Express.js, Apollo Server )

3. 클린 아키텍처 (Clean Architecture)

  - 애플리케이션의 비즈니스 로직을 외부 의존성(API, 데이터베이스 등)으로부터 격리하는 구조

  - 비즈니스 로직을 외부 의존성으로부터 격리해 유연성과 테스트 가능성을 제공

  - 아키텍처가 각각 의존성이 높게 설계되어 있다면 여러 개의 아키텍처를 통합하는 것이 쉽지 않다

  - 아키텍처부터 재구축해야 한다면 리소스가 많이 투여되어야 하거나 통합 자체가 되지 않을 수도 있다

  - 만약 의존성이 줄어든 클린 아키텍처로 설계되어있었다면 기능이 추가 및 서비스가 통합될 때마다 필요한 아키텍처만 뗐다 붙였다 하기 용이할 수 있다

  - 중대형 프로젝트에서 코드 구조를 체계적으로 유지 가능

  - 특징

    -- 도메인 중심 설계 (Domain-Driven Design, DDD)

    -- Ports and Adapters(Hexagonal Architecture)

    -- 계층 간의 의존성 규칙 (안쪽 계층은 바깥 계층을 참조하지 않음)

  - 알아야 할 도구

    -- 클린 아키텍처 템플릿

  - 구성

    -- 안쪽 : 엔티티(비즈니스 로직)

    -- 중간 : 유스케이스

    -- 바깥쪽 : 인터페이스 어댑터 및 외부 프레임 워크

  - 활용 사례

    -- 장기적으로 유지보수가 필요한 프로젝트

    -- 다양한 UI나 데이터베이스를 쉽게 교체해야 하는 경우

  - 장점

    -- 테스트 가능성이 뛰어나고 코드 재사용성을 높임

    -- 유지보수 및 확장이 용이

  - 단점

    -- 초기 설계가 복잡하고 구현에 시간이 걸림

4. 마이크로 서비스 아키텍처( MicroService Architecture )

https://kimyhg.tistory.com/39

5. 이벤트 기반 아키텍처 ( Event-Driven Architecture )

  - 애플리케이션이 이벤트(데이터의 상태 변화) 중심으로 작동하도록 설계

  - 이벤트의 상태 변화에 대응하는 소프트웨어 설계 패턴 / 이벤트 : 시스템의 외부 또는 외부에서 시스템에 영향을 주는 상황들(ex> 사용자가 로그인 버튼을 누른다, 문서를 열람한다, 구매한다. 등)

  - 고성능 및 비동기 처리가 요구되는 시스템에 적합

  - 시스템 간의 느슨한 결합과 실시간 데이터 처리가 가능

  - 비동기 작업 처리 방식(Publish/Subscribe, Message Queue)을 알아야 함

  - 알아야 할 도구

    -- 메시징 플랫폼 ( Apache Kafka, Amazon SNS/SQS )

    -- 클라우드 이벤트 서비스(GCP Pub/Sub, AWS EventBridge)

  - 활용 사례 : 

    -- 실시간 알림 시스템 ( Slack, WhatsApp )

    -- IoT 애플리케이션 ( 스마트 홈 기기 ) 

    -- 주식 거래 시스템 ( 실시간 거래 데이터 전송 )

  - 구조 :

    -- 프로듀서(이벤트를 생성)와 컨슈머(이벤트를 처리)로 구성

    -- 메시지 브로커 (Kafka, RabbitMQ )를 사용해 비동기적으로 통신 (이벤트 대기열을 관리하는 이벤트 중재자(Broker) )

    -- ex> 결제 서비스가 결제 이벤트를 처리하고 결제 완료 이벤트를 발생시키면, 다시 재고 관리 서비스로 이벤트가 전달되어 재고를 업데이트하는 

  - 장점 : 

    -- 비동기 작업으로 높은 확장성과 반응성 제공

    -- 느슨한 결합으로 변경에 유연

    -- 실시간성 시스템 (빠르게 반응해야 하는 시스템)

  - 단점 : 

    -- 디버깅과 문제 추적이 어려움

    -- 메시지 처리 실패 시 복구 로직이 필요

    -- 비동기 처리하므로 이벤트 순서 보장 어려움 --> 이벤트를 새로 받을지, 무시할지, 에러 처리를 할지 고려해야 함

6. 서버리스 아키텍처 ( Serverless Architecture )

  - 서버 관리 없이 클라우드 플랫폼의 이벤트 기반 함수(FaaS, Functions as a Service)를 통해 애플리케이션 실행

  - 코드가 이벤트에 의해 실행

  - AWS Lambda, Google Cloud Functions 등이 대표적

  - 변동적인 트래픽: 사용량이 예측하기 어려운 경우

  - 비용 효율성: 실제 실행 시간만큼만 비용을 지불하고 싶은 경우

  - 비용 효율적이며 특정 이벤트 기반 작업에 유용

  - FaaS(Function as a Service) 개념과 AWS Lambda, Google Cloud Functions 사용법

  - 서버리스와 데이터베이스의 결합(DynamoDB, Firebase)

  - 서버리스 배포와 모니터링 방법

  - 알아야 할 도구 : 

    -- AWS Lambda, Azure Functions

    -- 서버리스 프레임워크(Serverless Framework, AWS SAM)

  - 활용 사례:

    -- 데이터 변환 작업(ETL 파이프라인)

    -- 간단한 API 서버

    -- 비정기적 트리거 작업(예: 보고서 생성)

  - 장점 : 

    -- 인프라 관리 불필요

    -- 필요할 때만 실행되므로 비용 효율적

  - 단점 : 

    -- 클라우드 제공 업체에 의존적

    -- 긴 실행 시간이 필요한 작업에는 부적합

7. CQRS ( Command and Query Responsibility Segregation )

  - 쓰기 작업(Command)와 읽기 작업(Query)을 분리하여 각각 다른 모델로 처리

  - 읽기와 쓰기가 명확히 분리되는 경우, 읽기 작업 최적화가 중요한 시스템

  - 대규모 시스템에서 성능 최적화와 유연성을 제공

  - 쓰기 모델과 읽기 모델의 분리 방법, 이벤트 소싱과의 조합 설계, 데이터 동기화 전략

  - 알아야 할 도구 : 

    -- 이벤트 스토어(Event Store DB)

    -- 데이터베이스(Elasticsearch, MongoDB)

  - 활용 사례 :

    -- 대규모 데이터 조회가 많은 시스템

    -- 고성능 요구가 있는 금융 거래 시스템

    -- 이벤트 소싱과 함께 사용되는 애플리케이션

  - 특징 : 

    -- 쓰기와 읽기에 최적화된 데이터 모델 사용 가능

  - 장점 : 

    -- 읽기 성능과 쓰기 성능을 개별적으로 최적화 가능

  - 단점 : 

    -- 설계가 복잡하며, 데이터 동기화가 필요함

    -- 데이터 모델이 두 개 필요(쓰기 모델, 읽기 모델)

8. 분산 아키텍처 ( Distributed Architecture )

  - 애플리케이션의 여러 구성 요소를 물리적으로 분산된 시스템에서 실행

  - 대규모 시스템의 핵심 아키텍처로 높은 가용성과 확장성을 보장

  - 데이터 분산과 일관성 정리 (CAP 이론)

  - 분산 트랜잭션과 Saga 패턴

  - 서비스 간의 로드 밸런싱과 장애 복구

  - 알아야 할 도구

    -- 데이터베이스(Spanner, Cassandra)

    -- 분산 트레이싱 (Jaeger, Zipkin)

  - 활용 사례 : 

    -- 클라우드 기반 애플리케이션 ( ex> AWS, Google Cloud )

    -- 글로벌 사용자 기반의 애플리케이션

  - 장점 : 

    -- 높은 가용성과 확장성 : 장애 시에도 시스템을 지속적으로 운영 가능

    -- 다양한 지역의 사용자에게 낮은 지연을 제공

  - 단점 : 

    -- 분산 시스템의 복잡성 (데이터 일관성 문제, 네트워크 지연 등)

    -- 네트워크 지연, 데이터 일관성 문제 ( 캡 정리 - Consistency, Availability, Partition tolerance)를 해결해야 함

    -- 복잡한 모니터링과 디버깅 도구 필요

9. 서비스  메시 아키텍처 ( Service Mesh Architecture)

  - 마이크로서비스 간 통신, 보안, 트래픽 관리가 점점 중요해짐

  - 서비스 메시 도구 (Istio, Linkerd)

  - 트래픽 라우팅, 로드 밸런싱 설정

  - 보안 인증 ( MTLS, TLS )

  - 알아야 할 도구 : 
    -- Istio, Consul

    -- 오브저버빌리티 도구 ( Prometheus, Grafana )

10. 헥사고날 아키텍처 (Hexagonal Architecture , Ports and Adapters Architecture)

  - 애플리케이션 코어를 외부 의존성으로부터 격리 / 외부 의존성 : ex) 데이터베이스, UI )

  - 외부 의존성을 제거하고 비즈니스 로직을 테스트하기 용이한 구조

  - 장기적으로 안정적이고 유지보수가 쉬움

  - 어댑터 설계(ex> 데이터베이스 어댑터, API 어댑터)

  - 비즈니스 로직 중심의 설계

  - 언어별 클린 아키텍처 라이브러리 활

  - 활용 사례 : 

    -- 테스트 가능성을 높이고 싶은 프로젝트

    -- 비즈니스 로직을 외부 의존성으로부터 격리하고 싶은 경우

  - 테스트 주도 개발(TDD) : 비즈니스 로직을 독립적으로 테스트하고 싶은 경우

  - 특징 : 

    -- 코어 애플리케이션은 독립적으로 테스트 가능

  - 장점 : 

    -- 유지보수가 쉽고 테스트 친화적

    -- 유연한 구조 : 새로운 외부 시스템(API, DB 등) 을 쉽게 연결할 수 있음

  - 단점 : 

    -- 초기에 설계 복잡도가 높음

    -- 경험이 부족한 팀에는 낯설 수 있음

11. 그 밖의 아키텍처

  - 계층형 아키텍처(Layered Architecture)

  - 플러그인 아키텍처(Plugin Architecture)

  - 서비스 지향 아키텍처(Service-Oriented Architecture, SOA)

  - Peer to Peer(P2P) 아키텍처

  - Pipe and Filter 아키텍처

  - Pipeline 아키텍처

  - 마이크로커널 아키텍처(microkernel architecture)

  - 공간 기반 아키텍처(space-based architecture)

  - 공유 데이터 아키텍처(Shared Data Architecture)

  - 리액티브 아키텍처 (Reactive Architecture)

  - 객체 기반 아키텍처 (Object-Oriented Architecture)

  - 블록체인 아키텍처

  - 플랫폼 아키텍처(Platform Architecture) : 여러 애플리케이션이나 서비스를 통합해 작동하도록 설계된 플랫폼 중심의 구조