m1ndy5's coding blog

DDD? MSA? 멀티 모듈? 본문

Toy Projects/Ditto - Discuss Today's Topic

DDD? MSA? 멀티 모듈?

정민됴 2024. 1. 31. 18:03

DDD(Domain Driven Design, 도메인 주도 설계)란?

의미 그대로 도메인 위주의 설계 기법
도메인이란
특정 업무의 영역
ex) 음식 주문 배달 애플리케이션이라 가정했을 때 주문을 하는 고객, 실제 판매하는 음식점, 음식을 배달하는 배달원, 결재 담당인 카드사 혹은 은행 이렇게 나눠볼 수 있다. 따라서 크게보면 회원, 주문, 음식, 배달, 결제 도메인 간의 상호작용이 필요하다. 또한 큰 상위 도메인들도 더 작은 하위도메인으로 표현될 수 있다.(ex. 주문 - 주문자 정보, 음식 정보, 주문 정보, 배달 정보 등)

주요 설계 원칙

Loose Coupling(느슨한 결합)
다른 모듈과의 의존성이 낮을수록 좋다.
의존성이 높게 된다면 A모듈에서 코드를 수정하게 되면 B모듈, C모듈 등에서도 다 수정해야함
High Cohension(높은 응집)
모듈에 포함된 내부 요소들이 하나의 책임/목적을 위해 연결되어 있는 연관된 정도가 높을수록 좋다.
ex. 회원 도메인에서 주문이 들어간 이후 배차를 잡는 로직이 함께 들어가 있는 것보다 따로 분리하는 것이 더 좋음, 회원은 회원관련된 서비스만, 배달은 배달관련된 서비스만 할 수 있도록!

MSA(MicroService Architecture)란?

MSA는 DDD를 기반으로 아키텍처 패턴을 정의한 것
DDD의 설계 원칙이 MSA에 적용되면 도메인 내 마이크로서비스와 도메인 외 마이크로서비스로 구분
이에 따라 마이크로서비스 간의 커뮤니케이션 방식이 달라지게 됨

주요 설계 원칙

Strong Module Boundaries(명확한 모듈 경계)
모듈의 경계가 명확하면 시스템 내 변경 사항이 발생했을 때 변경할 특정 도메인 내 마이크로서비스 단위만 이해하고 처리하면 됨
제대로 된 경계를 가지지 못한다면 오히려 핸디캡이 될 수 있음
도메인을 잘 나누는 것이 MSA의 핵심 포인트!!
Independent Deployment(독립적 배포)
각각의 마이크로서비스를 독립적으로 배포할 수 있음
MSA가 배포 단위까지 고려해서 설계하기 때문에 CI/CD가 자동화되고 강화되기에 용이
Technology Diversity(기술 다양성)
각각의 마이크로서비스의 독립성이 강화되면서 마이크로서비스 내의 기술 선택이 자유로워짐
ex) 각 마이크로서비스가 다른 종류의 데이터베이스를 사용, 다른 언어를 사용하기 등
따라서 해당 서비스 도메인의 문제를 더 잘 해결할 수 있는데 적합한 기술 스택을 선택할 수 있음
다만, 너무 다양한 기술의 도입은 복잡성과 비효율을 초래할 수 있어 잘 조절해서 사용해야함

멀티 모듈이란?

Java에서 모듈이란 패키지의 한 단계 위의 집합체이며, 독립적으로 배포될 수 있는 코드의 단위
멀티 모듈 프로젝트는 상호 연결된 여러개의 모듈로 구성된 프로젝트
각 모듈은 독립적으로 빌드할 수 있는 것이 특징 -> 이 또한 모듈별로 다른 스택 사용 가능

멀티 모듈과 DDD, 그리고 MSA

DDD에는 바운디드 컨텍스트(bounded context)라는 개념이 존재하는데 이는 같은 모델이라도 특정한 컨텍스트에서 다른 의미를 갖고 구분되는 경계를 갖는 컨텍스트이다.
ex) 고객이라는 단어는 배달에서는 집주소의 정보에 관심이 있지만 결제에서는 결제 정보에만 관심이 있기 때문에 사실상 두 서비스에서 고객은 같은 고객이 아니다.
멀티 모듈을 사용하면 DDD의 바운디드 컨텍스트를 독립된 모듈로 분리할 수 있고 시스템을 더 작은 단위로 분해하여 복잡한 도메인을 더 쉽게 이해할 수 있다.
이런 멀티 모듈 프로젝트는 각각의 모듈이 독립적인 마이크로 서비스로 점진적으로 변화할 수 있다.

좋은 아키텍처는 시스템이 모노리틱 구조로 태어나서 단일 파일로 배포되더라도,
이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고,
또 독립적인 서비스나 마이크로서비스 수준까지 성장할 수 있도록 만들어져야한다.
또한 좋은 아키텍처라면 나중에 상황이 바뀌었을 때
이 진행 방향을 거꾸로 돌려 원래 형태인 모노리틱 구조로 되돌릴 수도 있어야 한다.
― 클린 아키텍처

멀티 모듈을 설계할 때 중요한 기준

앞서 바운디드 컨텍스트가 멀티 모듈의 기준이 된다는 것은 이해했다.
하지만 막상 설계를 해야한다고 생각해보니 막막해서 추가로 더 찾아보았고 유튜브에 올라온 강의를 볼 수 있었다.
https://www.youtube.com/watch?v=ipDzLJK-7Kc
일단 멀티 모듈을 나눌 때 크게 4가지의 특성을 가진 그룹으로 나눌 수 있다.
서버 모듈(잦은 변화)

  • batch, admin, api

데이터 모듈(+도메인)

  • meta, user, chart

연동모듈(큰 변화)

  • and, vod, photo, billing

클라우드(시스템)모듈(변화적음)

  • config, gateway, discovery, aws, gcp, azure

멀티 모듈 예시

https://www.daddyprogrammer.org/post/13156/spring-boot-change-multi-module/#google_vignette

참고
https://helloworld.kurly.com/blog/ddd-msa-service-development/
https://hudi.blog/why-use-multi-module/