Medium - Domain-Driven Design in the era of Microservices
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 마이크로서비스 시대의 도메인 기반 디자인; 생각보다 시사하는 바가 매우 많습니다.
Photo by chuttersnap on Unsplash
Oh how far DDD has brought us
DDD가 새로웠던 시절이 있었습니다. 에릭 에반스가 처음 출간했던 Domain-Driven Design: Tackling Complexity in the Heart of Software 책의 내용은 우리에게 많은 상처에 발라주는 연고 같았습니다. 에반스가 만들었던 것은 복잡한 로직을 구성하는 더욱 개선된 방식으로 코드 뿐만이 아니라 응용프로그램이 더욱 쉽게 이해될 수 있도록 했으며 코드들이 덜 흩어지게 해주고 중복된 작업이 난무하던 스파게티 코드들을 끝내게 해줬습니다.
그리고 나서 우리는 DDD와 함께 많은 성공을 이뤄냈습니다. 컨텍스트 맵에서 경계 컨텍스트를 잘라내는 방법이었을 수도 있고 도메인 서비스나 인프라스트럭쳐 로직을 구현하는 것이었을 수도 있고 심지어 구식 개발자에게 새로운 기법을 가르쳐 주는 것이었을 수도 있습니다. DDD 처럼 개발자가 생각하도록 다시 교육하는 것은 그냥 이전에 제가 만들었던 코드를 복붙하는 것이 아니었습니다.
그래서 한 때는 도메인 기반 디자인으로 이런 놀라운 것들을 해왔죠. 좋은 DDD 시스템을 구축하는 것은 상당한 투자이며 ( 때문에 여러분의 응용프로그램 로직이 타당한 이유로 복잡하지 않다면 DDD를 적용하지 않는 것을 추천드립니다. ) 그러나 이러한 투자로 얻는 것은 잘 구성된 도메인을 얻는 것보다 훨씬 많을 것 입니다.
다음은 DDD의 컨텍스트 경계를 나타내는 간단한 다이어그램입니다. ( 여러분의 이해와 다르더라도 이해부탁드립니다. DDD는 구현에 다양한 방법이 있기 때문입니다. )
A Bounded Context and the ways you interact with it
만약 여러분이 다른 방식으로 일한적이 없다면 행운아 이십니다. DDD 없이 복잡한 비즈니스 앱을 작업한 사람들은 여러분들에게 힘들었던 시절의 얘기를 들려줄 수 있을 것입니다. 현재 그런 구시대적이고 악몽같은 앱에다 작업을 하고 계시다면 애도를 표합니다.
Along come Microservices
얼마전부터 새로운 용어가 IT업계에서 돌아다니기 시작했습니다. 이 용어는 마이크로 서비스입니다. 마이크로 서비스가 무엇일까요? 흠, 어떻게 정의를 내리더라도 이 다음에 나오는 것 보다는 나을 거 같군요. 일단 위키피디아에 있는 것을 봅시다.
- 마이크로서비스는 소프트웨어 개발 기법으로 서비스 기반 구조의 한 형태로 응용 프로그램의 구조가 서비스들의 느슨한 결합으로 이뤄져 있습니다. 마이크로 서비스의 구조에서 서비스는 우수하며(fine-grained) 프로토콜은 가볍습니다.
인정합니다. 너무나 일반적인 말입니다. 다음 그림이 더 도움될 수 있겠군요.
A Microservice architecture and the ways you interact with it
마이크로 서비스는 단일 책임을 가지는데 자기들이 소유하고 제어할 수 있는 비즈니스 흐름의 일부만 담당합니다. 마이크로서비스들은 서로 통신하거나 외부와 통신하면서 제품 전체의 일부가 될 수 있습니다. 그래서 많은 비즈니스 로직들은 실제 작업하는 부분과 떨어져 있으며 그들의 활동분야만 책임지고 나중에 통신을 통해 하나의 일을 함께 수행합니다.
예를 한번 들어보겠습니다. 저의 제품은 실제로 더욱 작게 쪼개저서 서비스처럼 보이지도 않을 것입니다. 각각은 제품이 제공해야 하는 요건을 충족하고 작업 효율성을 위해서 서로 통신을 합니다. 마이크로서비스 구조에는 인증, 이벤트 퍼블리싱 / 섭스크라이빙 과 같이 더욱 많은 것이 있지만 이정도면 기본적인 개념은 이해하실 수 있을 겁니다.
Do Microservices play with DDD?
처음 슬쩍보고 생각하셨을 때는 DDD와 마이크로 서비스가 서로 잘 어울릴 거라고 생각하셨을 겁니다. DDD와 마이크로서비스 구조는 모두 작업 경계를 쪼개는 것이고 응용프로그램이 분산되도록 하고 필요 이상의 영역이 생기지 않도록 보장하는 것이죠. 마이크로서비스 구조는 DDD를 정제한 것처럼 보입니다. 하위 도메인 / 경계 컨텍스트를 더욱 분리해 놓은 것처럼 말이죠. 이런 직관은 꿈만같은 것이죠. 이론적으로 DDD를 사용한다는 말은 비즈니스 로직을 캡슐화를 하고 마이크로서비스로 결합도와 단일 책임을 지게 하는 것은 아주 멋진 이야기 입니다.
그러나 물론 이론적으로 봤을 때의 얘기죠. 실제로 적용해서 함께 사용하면 어떻게 어긋나게 되는지 알아봅시다.
Microservices as self-contained owners of data
마이크로서비스는 자체적인 개체라는 것을 기억하는 것이 중요합니다. 내부 로직에만 해당되는 것이 아니고 내부 데이터 그 자체 모든 것을 의미합니다. 이 말은 존재하는 데이터를 조회하거나 저장하는 것이나 데이터 구조 자체를 말합니다. 마이크로서비스의 데이터를 공유하는 것은 굉장히 큰 잘못입니다. 한 컨텍스트 경계에서 다른 컨텍스트 경계의 데이터베이스에 데이터를 주는 것과 마찬가지로 엄청 큰 실수 입니다. 이것은 다음의 이슈를 만들어 냅니다.
Microservices as self-deployable units of work
언제나 가등하다면 마이크로 서비스들의 서비스들의 구조는 자체적으로 배포가능해야 합니다. 여러분 제품의 전체적인 구조가 마이크로서비스로 녹아들어야 하며 하나의 영역이 다른 영역과 독립적으로 개발되고 배포될 수 있어야 합니다. 3개의 마이크로 서비스 중 1개만 변경해도 나머지 모두를 재배포 해야 한다면 아직까지는 귀찮지 않을 수 있습니다. 그러나 하나의 마이크로 서비스를 변경했을 때 x개의 다른 아미크로 서비스들이 성공적으로 배포되어야 하고 그렇다면 x가 높을 수록 여러분의 아키텍쳐가 나빠지는 것입니다.
So where does the Domain Model reside?
마이크로서비스 구조를 마주했을 때 제가 말하는 가장 큰 이슈중에 하나는 어디에 도메인 모델을 놔둘 것이냐 하는 것입니다. 전통적인 DDD 응용프로그램인 우리 도메인 모델은 자원을 공유하고 패키지나 에셈블리로 컴파일 되어 컨텍스트 바운드가 모든 응용프로그램 서비스, 저장소, 도메인서비스 들을 넘나들며 소비합니다. 아직 난제가 남아있는데 마이크로 서비스가 다른 것과 독립되어 배포되길 바란다면 어떻게 이것을 보장할 수 있을까요? 제가 도메인 모델을 업데이트해도 모든 마이크로 서비스가 업데이트할 필요가 없게 만들려면 어떻게 해야할까요? 제가 한것은 마이크로서비스 데이터를 DDD 패러다임 안으로 독립시킨 것입니다. 그래도 제 도메인 모델은 결합도를 유지합니다.
Summary
- 도메인 기반 디자인과 마이크로 서비스, 다시 정리할 것; 너무 어려움;
