MSA toy-project

MSA 와 DDD 의 차이

목표와 중점

• MSA: MSA는 애플리케이션을 작은, 독립적인 마이크로서비스로 분할하고, 이러한 서비스 간의 통신을 통해 확장성, 유연성 및 빠른 개발/배포를 강조합니다. MSA는 주로 애플리케이션의 아키텍처 및 인프라스트럭처 측면에서 관심을 둡니다.

• DDD: DDD는 비즈니스 도메인 모델을 중심으로 소프트웨어를 설계하는 방법론으로, 비즈니스 도메인의 복잡성을 이해하고 그에 맞춰 소프트웨어를 구조화하는 것을 강조합니다. DDD는 주로 비즈니스 도메인 모델링 및 그 모델을 코드로 반영하는 데 중점을 둡니다.

범위

• MSA: MSA는 애플리케이션의 아키텍처 레벨에서 작동하며, 서비스 간 통신 및 인프라스트럭처 관리와 관련이 있습니다. 이는 개발자, 운영팀 및 인프라 엔지니어에게 영향을 미칩니다.

• DDD: DDD는 비즈니스 도메인 모델링과 관련이 있으며, 주로 소프트웨어 개발자 및 비즈니스 전문가에게 영향을 미칩니다. 비즈니스 도메인 모델은 비즈니스 로직과 관련된 부분을 다루므로 개발팀과 비즈니스팀 간의 협력을 강조합니다.

주요 도구와 기술

• MSA: MSA를 구현하기 위해 주로 서비스 디스커버리, 컨테이너 오케스트레이션 (예: Kubernetes), API 게이트웨이 및 분산 시스템 통신 도구 등과 관련된 기술과 도구를 사용합니다.

• DDD: DDD를 구현하기 위해 주로 도메인 주도 설계 원칙, 엔터티와 밸류 객체 모델링, 어그리게이트 루트, 리포지토리 패턴 등과 관련된 개념과 도구를 사용합니다.

변경 관리:

• MSA: MSA는 애플리케이션을 작은 서비스로 분리하여 변경 관리를 용이하게 만듭니다. 각 서비스는 독립적으로 배포 및 확장될 수 있으므로 특정 서비스의 변경이 전체 시스템에 미치는 영향을 최소화합니다.

• DDD: DDD는 비즈니스 도메인의 복잡성을 관리하고 변경에 대응하기 위한 구조를 제공합니다. 비즈니스 규칙이 변경되면 해당 규칙을 반영하는 도메인 모델의 수정이 필요하며, 이는 비즈니스 변화에 더 직접적으로 관련됩니다.

요약하면, MSA는 애플리케이션 아키텍처와 인프라스트럭처에 중점을 두며, 확장성과 빠른 개발을 강조합니다. 반면 DDD는 비즈니스 도메인 모델링과 비즈니스 도메인의 복잡성 관리에 중점을 두며, 소프트웨어를 비즈니스 요구 사항과 일치시키기 위해 사용됩니다.

---

배민을 예시로 .. 기획..

1. Eureka Server : netty 기반의 non-blocking 과 lb 를 이용하여 Eureka Netflix server로 msa 프로젝트를 관리 할 예정..

2. Config Server : 각각의 프로젝트에서 사용할 config 셋팅을 github를 참조하여 server를 띄워 관리할 예정..

3. GateWay Server : 각각의 프로젝트에 요청을 나눠주는 역할과 필요하다면 사전 default filter 등을 적용할 예정..

4. Auth server : 인증서버를 따로 두고 인증 서버를 통과하는 유저들은 토큰에 각자의 role을 부여해서 요청 및 서비스를 나눠 줄 것임.. 회원가입과 로그인은 인증서버를 거칠 예정..

5. Owner Server : 어플을 사용하는 가게 사장님들이 사용하는 서비스

6. Store Service : Owner 의 하위 도메인

7. Menu Service : Store 의 하위 도메인

8. Customer Service : 어플을 사용하는 일반 사용자들이 사용하는 서버

9. Payment Service : Customer 의 하위 도메인

10. Order Command Service : Order 도메인의 CQRS - CREATE SERVER ( h2 )

11. Order Query Server : Order 도메인의 CQRS - READ SERVER

가장 큰 의미는 하나의 Server 가 죽었다고 해서 다른서버에 영향을 끼쳐선 안된다..

아래는 그림으로 보는 설계 기획이다.

1. 모든 Service 는 Eureka Server 에서 관리할 것 이다.

   • Service Discovery

   • Load Balancer

   • High Availability

   • Eureka 에서 각각의 Service 끼리의 소통은 OpenFeign 을 사용

2. FE 에서는 모두 GateWay 로 Request ..

3. GateWay 에서는 셋팅해놓은 곳으로 Request를 나눠 준다.

   • Netty

   • Non Blocking

4. Auth 에서는 로그인과 회원가입 기능을 담당

   • 회원가입 시 해당 유저의 ROLE 에 따라서 해당하는 Service로 보내준다.

   • 로그인 시 JWT 발급

5. Owner 에서는 각각의 필요한 method 들을 만든다. Store와 1 : N 관계를 가진다.

6. Store 도 각각의 필요한 method 들을 만든다. Menu와 1 : N 관계를 가진다.

7. Menu 도 각각의 필요한 method 들을 만든다.

8. Customer 도 필요한 method 를 만든다.

9. Pay 도 필요한 method 를 만들고 pay 가 적재 될 시 OrderCommand 로 데이터 전달

10. OrderCommand 에서는 Create Server 의 역할을 한다. Inmemory H2 에 같이 적재를 시도하고, Reac Server 인 OrderQuery 에 정상적으로 적재가 되었다면 적재 되었던 H2에서는 delete..

11. OrderQuery에 적재되지 않았다면 그 내역들은 H2 에 적재가 되어 있을 것.. H2에 적재되어 있는 Data 는 1분에 한번씩 batch 로 다시 OrderQuery에 밀어넣어서 data 손실을 막는다.