DEVOCEAN

안녕하세요. 해리쓴입니다.

오늘 제가 풀어볼 주제는 마이크로서비스에 대해 공부하다 한번쯤은 들어보셨을 도메인 주도 설계(DDD, Domain-Driven Design)입니다.

먼저 당연한 얘기지만 어떤 소프트웨어가 좋은 소프트웨어인지 한번 짚고 넘어가겠습니다.

소프트웨어의 본질, 올바른 소프트웨어는?

소프트웨어의 본질은 소프트웨어는 현실 세계의 복잡한 프로세스를 자동화 하거나, 비즈니스의 어렵고 복잡한 문제를 시스템을 통해 쉽게 할 수 있게 하는데 있습니다.

당연한 얘기를 어렵게 적은 것 같네요. ^^

이런 복잡하고 어려운 비즈니스 도메인을 소프트웨어로 구현하기 위해서는 도메인을 바르게 이해하는게 중요합니다.

따라서, 도메인 전문가, 개발자 등 프로젝트에 참여한 모든 구성원들은 도메인을 잘 이해하는데 많은 노력을 해야 합니다.

다시말해, 우리는 도메인의 이해와 도메인 중심의 사고를 바탕으로 소프트웨어를 만들어야 한다라는 거죠.

이게 도메인 주도 설계가 필요한 이유입니다.

도메인 주도 설계는?

도메인 주도 설계는 도메인의 가치를 최우선시하는 모델링 기법으로 개발자들도 분석과 설계자와 함께 회의에 참석하고,

코드를 구현하기에 앞서 도메인과 도메인 모델을 명확히 이해하고 또 완전한 이해를 강조하고 있습니다.

즉, 도메인 주도 설계는 크고 복잡한 도메인을 이해하고 탐구하는 활동을 하고,

이를 통해 발견된 다양하고 많은 도메인의 문제들을 해결하기 위한 소프트웨어 개발의 철학이라고 할 수 있습니다.

많은 소프트웨어 개발 프로젝트를 수행하는 것을 보면, 특히 소프트웨어를 설계할 때 흔히 벌어지는 일이 있습니다. 소프트웨어 설계는 처음에는 중요한 것들부터 작게 설계가 시작됩니다.

설계가 계속 진행되면서 팀원들은 본인이 담당하는 업무와 관련된 다양한 내용을 설계에 계속 추가하게 됩니다.

복잡한 도메인에 대한 이해와 탐구가 부족한 상태에서 각각의 담당 업무와 관련된 내용을 계속해서 식별하고 추가를 하게 됩니다.

이런 것들이 설계가 진행되는 내내 발생되고 반복되면서 비즈니스 상 중요한 것과 덜 중요한, 어쩌면 중요하지 않은 것들이 아래 그림처럼 하나의 큰 덩어리로 얽히게 됩니다.

이렇게 만들어진 설계를 기반으로 구현된 코드는 가독성이 떨어지고, 또 많은 기능이 하나로 엮여 새로운 기능의 추가나 개선 등의 유지보수를 어려워지게 만드는 문제가 있습니다.

이런 문제를 방지하거나 최소화할 수 있는 설계 기법이 도메인 주도 설계입니다.

도메인 주도 설계에서는 전체 비즈니스가 한 덩이로 된 위의 그림과 같은 소프트웨어를

아래 그림처럼 비즈니스 상 중요도에 따라 서브 도메인들로 나누고, 또 나눠진 것들을 하나씩 해결해 나갈 수 있게 합니다.

도메인 주도 설계에서는 서비스의 설계를 2개 단계로 정의하고 있습니다.

서비스를 식별하는 설계를 전략적 설계, 서비스 내부 구조를 상세하게 정의하고 비즈니스의 고유한 활동을 모델링하는 것을 전술적 설계라고 합니다.

그럼 전략적 설계와 전술적 설계를 알아보겠습니다.

전략적 설계

전략적 설계는 하나의 큰 비즈니스 도메인에서 마이크로서비스를 식별하는 것으로, 첫 번째로 유비쿼터스 언어를 정의하는 것입니다.

유비쿼터스 언어는 소프트웨어를 개발하는 팀 안에서 사용하는 공통의 언어로,

이 공통의 언어를 활용해서 비즈니스를 분석하고 핵심이 되는 개념을 식별하게 됩니다. 이렇게 식별된 개념들을 분석해서 Bounded Context를 식별하고,

식별된 Bounded Context 간의 매핑 관계를 정의해서 Context map을 만들게 됩니다.

그리고 최종적으로 Bounded Context로의 분할에 따른 효과를 분석해서 서비스의 추가적인 분할이나, 다른 서비스와의 통합을 검토하여 후보 마이크로서비스를 도출합니다.

이렇게 전략적 설계를 통해 장차 마이크로서비스가 될 후보를 도출해 내게 됩니다.

위의 알록달록한 이미지는 전략적 설계를 "이벤트 스토밍"이라는 방법으로 도출한 예시인데, 조만간 이 기법에 대해서도 정리해 보겠습니다.

전술적 설계

전술적 설계는 식별된 마이크로서비스의 내부를 설계하는 것으로, 비즈니스의 고유한 활동을 정확하게 모델링하는 설계하는 방식들을 의미합니다.

전략적 설계를 통해 도출한 후보 마이크로서비스별로 서비스의 내부 구조를 상세히 정의하고,

도메인 모델과 모듈, 서비스 인터페이스와 API 그리고 프론트 엔드의 설계를 전술적 설계를 통해 수행하게 됩니다.

이 결과물을 도메인 모델이라고 하며 도메인 모델은 비즈니스의 핵심 개념을 도메인 객체로 표현한 것으로 UML의 Class Diagram의 형태로 그려지게 됩니다.

• 이 다이어그램은 각 바운디드 컨텍스트 별로 모델링하고 전체 도메인 모델을 하나의 다이어그램을 통합, 전략적 설계 단계어서 정의했던 서비스 간 매핑 정보를 추가했습니다.

정리

도메인 주도 설계는 소프트웨어로 만들어내야 할 비즈니스에 대해 도메인 전문가와 개발자들의 도메인의 이해에 대한 눈높이를 맞춤으로써

도메인의 문제를 정확히 해결할 수 있는 좋은 소프트웨어를 만들 수 있게 합니다.

또한 유비쿼터스 언어를 정의해서 사용함으로써 도메인 전문가와 소프트웨어 개발자 그리고 소프트웨어 사이에 도메인을 이해하고 탐구하는데,

서로 간에 용어 차이로 인해 발생하는 오해를 설명하는 일종의 번역이 필요하지 않게 됩니다.

프로젝트 팀원 모두가 동일하게 이해하고 표현하는 공통의 언어를 사용해서 프로젝트 팀이 개발을 하게 되기 때문입니다.

이 유비쿼터스 언어의 활용은 한 용어를 다른 개념으로 이해해서 발생되는 잘못된 설계와 구현을 사전에 방지하게 해주게 되어 좋은 소프트웨어를 만드는 데도 기여를 하게 됩니다.

따라서 소프트웨어 개발에 도메인 주도 설계 기법을 적용해서 비즈니스의 복잡한 문제를 잘 해결할 수 있는 올바른 소프트웨어를 만드는 데 도움을 받을 수가 있습니다.

도메인 주도 설계는 에릭 에반스가 정의했고, 서적으로는 2004년도에 발간이 되었는데 우리나라에는 2011년도에 번역서가 발간되었으니까 약 7년 정도의 차이가 있습니다.

초기에는 이런 설계 기법에 대한 관심이나 필요성을 느끼지 못하다가 최근 클라우드 환경으로 전환이 진행되면서

클라우드 마이크로서비스 아키텍처에 최적화된 애플리케이션 개발을 위한 설계 기법으로 도메인 주도 설계가 다시 주목을 받게 된것 같습니다.

그래서 저도 도메인 주도 설계에 대한 책도 한권 썼습니다.

책이 나온지 몇 년 지나기도 했고, 요즘 좋은 책들이 많이 나왔으므로, 책 이름은 공개하지 않겠습니다. ^^

감사합니다.