Monolithic Architecture

- 서비스를 추가한다거나 리포지토리를 추가 한다거나 external system을 추가한다고 했을 때, 하나의 서버에서 다 진행됨
- 가장 큰 어려움
- 코드가 너무 길어짐 → 유지 보수가 힘들어짐
- 사소한 수정하나에 전체를 다 배포해야함(A Service한개에서 row level을 수정했을 때 다 배포해야하고)
- DB를 하나만 쓰기 때문에 db 기술 선택폭이 좁아짐
- 기술 발전을 해도 버전 업그레이드 하기가 힘듦. 하나 업그레이드 하면 전체에 다 영향을 미치니까
Microservice Architecture
- 개발자 수가 적을 때는 큰 의미가 없음. 그럴 때는 Monolithic Architecture가 나음

- 마이크로 서비스는 독립적으로 배포가능한 서비스들이고
- 네트워크를 통해서 서비스에서 제공하는 기능들을 이용가능하게 함.(Http, Grpc, tcp)
- 서비스별로 도메인을 맡아서 진행됨
- 핵심 개념
- Independent Deployability
- Modeled Around a Business Domain (서비스 별로 도메인이 나뉜다)
- Owning Their Own State (독립적으로 별도의 db를 쓴다)
- Alignment of Architecture and Organization(조직과 align되어 있어야 한다. 즉, 마이크로 서비스와 조직간의 관계가 맞춰져 있어야 함. 하나의 조직이 하나의 마이크로 서비스를 관리하는. 하나의 조직이 여러 마이크로 서비스를 관리하는 것은 align이 되지 않은것. 하나의 조직이 해당 도메인 전문가들로 구성되어 있는 집단)
Microservices - Modeling
Domain-Driven Design
Domain
: 해결하고자 하는 비즈니스의 영역. 해당 비즈니스를 해결하기 위해서 어떻게 설계 할 것이냐
- 하나의 Domain은 여러 개의 Sub-domain으로 나뉘어짐

- sub-domain(Bounded Context) 단위로 마이크로 서비스를 구성할 수 있음(이 영역을 쪼개는 부분이 Microservice 설계에서 중요함)
- 그 안에 여러 개의 entity가 존재할 수 있고 그것을 이용하여 마이크로 서비스를 구성
- Sales Context와 Support Context에서 동일한 entity를 공유할 수 있는데 같은 entity라도 context별로 조금 다른 내용을 가짐
- 그 entity들 끼리 연결은 reference id (primary key)로
필수 용어

- 시퀀스 다이어그램, 오브젝트 다이어그램 이런 것들을 코딩하기 전에 디자인을 하고 코딩을 시작해야함
Microservices - 커뮤니케이션

비동기 방식
: Message Broker(Event bus)를 이용- 메시지 종류 : Event, Command
- 장점
- 의존성을 줄여준다
- 초당 수천만건의 메시지를 처리 할 수 있음. 실제 OrderService의 처리 속도에 맞게 시스템을 구성할 수 있어서 더 안전함. CustomerService가 1초에 100건 요청하는데 OrderService는 1초에 10건만 가능하다?? 이러면 죽게 됨. 그러나 Message Broker를 이용하면 OrderService가 필요할 때마다 긁어감
- 비즈니스 flow가 loosely-coupled됨 ⇒ CustomerServiced에서 customer signup이라는 event를 발생시키면 해당하는 것을 OrderService에서 그에 맞는 처리를 진행하면됨. direct하게 실행시키는 것이 아니라
- 단점 :
- compile타임에 오류를 발견하기 힘듦. 런타임에 오류가 발생함
동기 방식
: Http, RPC, gRCP
Microservices - Data Ownership

- 원하는 기능에 맞는 db를 선택할 수 있는 장점
- 빠른 write가 보장되고, schema에 대한 자유도가 보장되는 곳, scale out도 잘 되고 → Nosql db 가 더 적합함
Microservices - Tech Stack

- 요구 사항에 맞는 적절한 기술을 고를 수 있다
Microservices - API Gateway

- 클라이언트와 API 서버 앞에서 일종의 프록시처럼 위치 하여 다양한 기능을 수행함
- api 요청의 orchestration을 API gateway에서
Microservices - Deployment
- 각각 마다 배포를 해야 하기 때문에 Kubernetes를 도입해야 함
- 컨테이너 오케스트레이션 이런 것들이 필요해지게 됨
Event-Driven Architecture
도메인 이벤트란?
- A representation of something that happend in the domain.(DDD. Eric Evans)
- A domain event is, something that happend in the domain that you want other parts of the same domain(in-process) to be aware of. (Microsoft docs)
→ 도메인 모델에서 어떤 일이 일어 났을 떄(상태가 변경된다거나) 이를 대표하는 이벤트를 도메인 이벤트라고 하고 다른 도메인에 이를 알리고 자신의 상태를 변경할 수 있음
오직 이벤트에 의해서만 도메인의 상태가 바뀌게 되는 것

- User가입시 이메일 발송하자 → UserService에 Email Notification Service DI를 넣어서 직접 호출하도록 하는거
- 이렇게 되면 UserService에 비즈니스가 계속해서 추가가 되게됨

- User가입 했다. 해당 이벤트를 구독하는 Subscriber에서 UserJoin이벤트를 Subscribe하도록 하여서 이메일 보내도록 하기
- 이렇게 하면 loosely-coupled되는 것.
