DDD(Domain Driven Development) 도메인 주도 개발
0
여태까지 경험한 서비스들은 완전한 MSA 아키텍처는 아니 였으며, 일부 도메인 별로 서비스를 구축하여 운영하였습니다.
MSA 아키텍처 도입에는 초기 리소스 비용도 많이 들고, 생산성도 좋지 못하고, 관리 포인트도 많아지기 때문입니다.
하지만 서비스의 규모가 커지거나 복잡한 시스템의 경우 MSA 아키텍처로 구성해야 서비스의 장애전파가 확산되지 않으며, 독립적인 도메인이기 때문에 개별 서비스마다 확장에 용이하기 때문에 큰 규모의 서비스를 운영하는 기업에서는 많이 도입하는 추세로 보여집니다.
그렇기에 MSA 아키텍처와 잘 조화를 이루는 DDD(도메인 주도 개발) 방법론에 대해 알아보려 합니다.
목차
- MSA란?
- MSA의 장단점
- DDD란?
- DDD의 장단점
- MSA 아키텍처에 DDD 개발방법론을 적용하면 어떠한 효과가 있는가?
- DDD를 적용한 MSA 아키텍처 구성은 어떻게 하는가?
MSA 란?
- MSA는 소프트웨어를 독립적인 작은 서비스로 나누어 개발하고 운영하는 아키텍처 패턴입니다.
- 각 서비스는 독립적으로 배포되고 확장되며, 특정 비즈니스 도메인이나 기능을 담당합니다.
- 각 서비스 간의 통신은 API를 통해 이루어지며, 비동기 메시징이나 RESTful API가 자주 사용됩니다.
MSA의 장단점
장점
- 유연성과 확장성: 각 서비스는 독립적으로 개발, 배포, 확장 가능하므로 전체 시스템이 더 유연하고 확장 가능합니다.
- 기술 다양성: 각 서비스는 독립적으로 기술 스택을 선택할 수 있어, 특정 기술에 종속되지 않고 적절한 기술을 선택할 수 있습니다.
- 느슨한 결합: 각 서비스는 독립적으로 동작하므로, 한 서비스의 변경이 다른 서비스에 미치는 영향을 최소화할 수 있습니다.
단점
- 운영 복잡성: 분산 시스템이므로 운영 및 모니터링이 복잡해질 수 있습니다.
- 데이터 관리: 서비스 간의 데이터 일관성을 유지하기 위해서는 추가적인 노력이 필요합니다.
DDD 란?
- DDD는 비즈니스 도메인에 중점을 두고, 도메인 모델링을 통해 비즈니스 요구사항을 이해하고 구현하는 방법론입니다.
- 유비쿼터스 언어를 사용하여 비즈니스 전문가와 개발자 간의 소통을 촉진합니다.
- 도메인 모델은 비즈니스 도메인의 핵심 개념을 표현하며, 소프트웨어의 설계와 개발에 이를 반영합니다.
DDD의 장단점
장점
- 비즈니스 이해: 비즈니스 도메인에 집중하므로 개발자들은 비즈니스 요구사항을 더 잘 이해하고 모델링할 수 있습니다.
- 높은 응집도: 도메인 모델링을 통해 각 요소가 높은 응집도를 갖게 되어 코드의 가독성과 유지보수성이 향상됩니다.
단점
- 초기 비용: 도메인 모델링은 초기에 시간과 노력을 많이 요구할 수 있습니다.
- 복잡성: 복잡한 도메인에서는 모델링이 복잡해질 수 있습니다.
MSA 아키텍처에 DDD 개발방법론을 적용하면 어떠한 효과가 있는가?
- 비즈니스 도메인에 집중하므로, 개발자들이 비즈니스 요구사항을 더 잘 이해하고, 더 나은 소프트웨어를 만들 수 있도록 해줍니다.
- 서비스에 대한 경계를 명확히 정의하고 서비스 간의 느슨한 결합도를 유지할 수 있습니다.
- 도메인 전문가와 소프트웨어 개발 전문가들이 다 이해할 수 있는 용어들을 사용함으로써 각각의 서비스가 일관성을 유지 할 수 있습니다.
DDD를 적용한 MSA 아키텍처 구성은 어떻게 하는가?
도메인 주도 설계는 크게 4가지로 구분한다.
- 유비쿼터스 언어(Ubiquitous Language)의 정의
- 바운디드 컨텍스트(Bounded Context)의 식별
- 컨텍스트 맵
- 이벤트 스토밍
유비쿼터스 언어(Ubiquitous Language)의 정의
- 도메인 전문가, 기획자, 디자이너, 개발자 등 다양한 직군들이 모여 비즈니스의 도메인에 대한 공통된 용어를 도출
바운디드 컨텍스트(Bounded Context)의 식별
- 특정한 도메인 모델이 적용되는 제한된 영역 경계 내에선 동일한 모델을 일관되게 적용
컨텍스트 맵
- 바운디드 컨텍스트 간의 관계 설정
이벤트 스토밍
- 개발 참여자들이 모두 모여 전략적 설계에 대한 고민을 하며, 이벤트 및 기능에 대한 정의 흐름에 대한 다이어그램 작성 등을 시각화하여, 참여자 모두가 이해 할 수 있도록 수정과 논의를 통해 반복적 진행
결론
DDD 방법론을 적용하여 설계를 할때는 많은 리소스가 든다. 그리고 막상 하려면 어렵고 뭔가 장황하다.
위의 내용으로 함축적으로 정리해보려한다.
DDD(도메인 주도 개발) 방법론 기반으로 MSA 아키텍처를 설계할때는 개별 도메인(역할) 단위로 분리하고, 그 안에서 사용자에 의해 인식되는 기능들을 정의하고 그 기능 사이의 이벤트를 정의하는 것
결국 도메인 주도 개발이라는 것은 사용자에 초점을 맞춰 개발하는 것이기 때문이다.
참조
https://incheol-jung.gitbook.io/docs/q-and-a/architecture/ddd
https://velog.io/@roo333/DDDDomain-Driven-Design
어제보다 오늘이 더 나은 개발자