📌 1. 기본 구조 (모놀리식 Monolithic)

한 프로젝트 안에 모든 코드가 들어있는 형태

• controller, service, repository 쭉 하나에 다 있음
• 하나의 JAR 혹은 WAR로 배포
• DB도 보통 하나
• 개발 속도는 빠르지만 규모가 커지면 복잡해짐

특징

• 쉬움
• 하나만 배포하면 됨
• 팀이 커지면 충돌 많고 유지보수 힘듦
• 어떤 기능 하나만 바꿔도 전체를 다시 빌드/배포해야 함

---

📌 2. DDD (Domain-Driven Design)

모놀리식 구조이긴 하지만 도메인을 기준으로 코드 구조를 나누기 시작함

기존:

controller/
service/
repository/

DDD 적용 후:

user/
    controller/
    application/
    domain/
    infra/
order/
    controller/
    application/
    domain/
    infra/

핵심

• 비즈니스 도메인(회원, 주문, 결제 등) 중심으로 나누기 때문에 유지보수 쉬워진다
• 실질적으로 모놀리식이지만 내부가 “도메인별로 격리됨”
• 마이크로서비스로 가는 기초 체력 마련 단계

---

📌 3. 멀티 모듈 (Multi-Module Monolith)

DDD 구조를 더 강하게 적용해서 도메인별 모듈을 실제로 분리함

예:

app (메인)
 ├── user-module
 ├── order-module
 ├── payment-module

각 모듈은 서로 독립적인 코드 집합이고
모듈 간에는 내부 구현을 직접 참조할 수 없게 막을 수도 있음.

장점

• 경계가 더 명확해짐
• 하나의 거대한 프로젝트 안에서 모듈이 독립적으로 개발됨
• 마이크로서비스로 쪼개기 쉬워짐 (복사 후 독립 서비스화 가능)

여전히 모놀리식이지만, 내부 구조가 엄청 깔끔해짐.

---

📌 4. MSA (Microservice Architecture)

멀티 모듈까지 왔다면 이제 각 모듈을 완전히 독립시켜 각각 별도 서버 / 별도 배포로 만들어버림.

예:

• user-service
• order-service
• payment-service
• notification-service

서로 통신하는 방법

1. API 호출 (Sync 통신)

   • REST / gRPC
   • 예: order-service → user-service (사용자 정보 조회)

2. 이벤트 기반 통신 (Async 통신)

   • Kafka, RabbitMQ, SNS/SQS
   • 예: order-service → "주문 생성됨" 이벤트 발행
     payment-service가 이걸 구독하고 결제 처리 시작

장점

• 서비스별로 독립 배포
• 특정 서비스만 스케일 아웃 가능
• 장애 격리(주문 서비스 죽어도 결제는 살아 있음)

단점

• 복잡성 증가
• 네트워크 비용/지연
• 분산 트랜잭션 문제
• 운영 비용 증가

---

📌 전체 흐름 요약

단계	구조	복잡도	특징
1. 모놀리식 기본 구조	모든 코드 한 곳	낮음	빠른 개발, 유지보수 어려움
2. DDD 구조	모놀리식 + 도메인 단위 정리	중간	도메인 경계 생김
3. 멀티 모듈	모놀리식이지만 모듈로 실제 분리	중간	아키텍처가 견고해지고 MSA 준비 완료
4. MSA	각 도메인을 완전히 분리하여 독립 서비스화	높음	고도화된 운영 필요

---