도메인 중심 설계 개발 철학을 마이크로서비스에 적용하는 방법

도메인 중심 설계에서 마이크로서비스까지

도메인 중심 설계 개발 철학을 마이크로서비스에 적용하는 방법

많은 분들이 기억하시겠지만 SOA(서비스 지향 아키텍처)로 알려진 소프트웨어 설계 및 아키텍처 스타일은 1990년대 중반에 등장했습니다. 그 이후로 우리는 클라우드 기반 가상화, 지속적인 통합 및 제공, 마이크로서비스의 발전을 포함하여 시스템을 구축하는 더 나은 방법을 발견했습니다. 그 과정에서 이러한 기술은 SOA와 관련된 모든 이점을 현실로 만들었습니다.

11월에 저는 잘 정립된 레거시 시스템을 갖춘 대규모 조직에 마이크로서비스를 도입하는 방법 에 대해 자세히 설명 했습니다. 이 게시물에서는 도메인 기반 설계(DDD)와 이 개발 철학이 마이크로서비스 구현에 적합하면서 코드로 실제 세계를 표현하는 데 어떻게 사용될 수 있는지를 다룹니다.

도메인 중심 설계

응집력은 소프트웨어 설계의 초기 신조이며 모듈 또는 클래스 내부에 존재하는 기능적 관련성의 정도를 나타냅니다. 이러한 맥락에서 응집력은 1970년대 후반 Tom DeMarco에 의해 처음 설명되었으며 동일한 이유로 변경되는 항목을 그룹화 및 유지하고 다른 이유로 변경되는 기능을 분리하는 것을 의미하게 되었습니다.

DDD는 제한된 컨텍스트를 통해 응집력이 높은 시스템의 개발을 용이하게 하는 방법을 제공합니다. 마이크로서비스는 비즈니스 도메인 경계에 서비스 경계를 집중하도록 권장하는 구현 접근 방식입니다. DDD와 마이크로서비스는 조직을 서비스 지향 설계로 전환하고 지속적인 통합 및 제공의 이점을 누릴 때 함께 사용할 수 있습니다.

DDD의 획기적인 작업은 2003년 Eric Evans의 Domain-Driven Design: Tackling Complexity in the Heart of Software 라는 책에 정의되어 있습니다. DDD의 가장 중요한 철학은 비즈니스 도메인을 정의하는 모델 주위에 보호 레이어를 형성하는 경계 컨텍스트의 개념을 사용하는 것입니다. 경계 컨텍스트는 회사의 부서와 유사합니다. 법무 부서에는 IT 부서와 다른 특정 책임(컨텍스트)이 있으며 이러한 책임은 부서에서 서비스를 받고 상호 작용하기 위한 규칙(경계)에 의해 시행됩니다.

이것은 DDD를 사용하여 모델링하는 제한된 컨텍스트에 대해서도 동일합니다. 문제 영역에 대한 공통의 이해를 촉진하고 해당 영역 지식을 컴퓨터 시스템으로 변환하려면 비즈니스 및 기술 팀이 공통 언어를 개발해야 합니다. DDD에서 이 공용 언어를 유비쿼터스 언어(UL)라고 합니다. 기술 직원이 모델과 코드를 개발할 때 UL을 사용하여 프로젝트가 진행됨에 따라 비즈니스 분석가와 엔지니어링 직원 간의 오해 위험을 줄입니다.

이것은 또한 시스템 문서화의 추가 계층을 제공하고 시스템이 어떻게 설계되고 작동하도록 의도되었는지에 대한 조직의 이해를 향상시키는 역할을 합니다. 도메인을 이해하고 정의하는 데 사용되는 분석 모델은 UL에서 소프트웨어를 만드는 데 사용되는 코드 모델과 연결되어 있습니다.

DDD의 다른 주요 원칙은 다음과 같습니다.

• 분석 및 코드 모델의 반복 생성. 팀은 도마이에 대해 더 많이 알게 되면 분석 및 코드 모델을 반복하면서 둘 다 동기화된 상태로 유지합니다. DDD는 도구, 데이터베이스 또는 언어를 지정하지 않지만 UML(Universal Modeling Language)을 사용하여 분석 모델을 만들고 코드 또는 구현 모델을 C++ 및 Java로 수행했습니다.
• 비즈니스 및 기술 팀의 협업을 위해서는 관련 모델을 생성하기 위해 긴밀한 대면 협업이 필요합니다. 이는 모든 당사자가 UL을 개발하고, 이를 사용하여 도메인을 정의하고, 도메인 정의를 반복하고, 솔루션으로 직접 점프하는 대신 문제에 집중하기 위한 중대한 약속입니다.
• 핵심 영역에 집중하십시오. 핵심 영역은 제품을 성공으로 이끄는 영역입니다. 비즈니스의 성공에 절대적으로 필요한 경우 핵심 영역입니다. 이 도메인이 어떻게 수익을 늘리고, 비용을 절감하고, 효율성을 높이는지, 그리고 왜 이 도메인이 비즈니스에 중요한지 자문해야 합니다.
• 해결하고 있는 문제는 상당해야 합니다. 중요하지 않거나 비즈니스에 도움이 되지 않거나 상용 기성 솔루션으로 더 잘 해결되는 문제에는 DDD를 구현해도 소용이 없습니다.

비즈니스 문제를 이해하기 시작하고 이를 정의하기 위한 모델을 개발한 후에는 제한된 컨텍스트를 통합하는 방법에 대해 생각해야 합니다. Gregor Hohpe와 Bobby Woolf는 그들의 책 Enterprise Integration Patterns (Addison Wesley Signature Series)에서 파일 전송, 공유 데이터베이스, 원격 프로시저 호출 및 메시징의 네 가지 통합 스타일을 정의합니다. 상당한 규모의 대부분의 응용 프로그램에서 응집력을 이유로 DDD와 기술 팀은 통합을 위한 원격 프로시저 호출 및/또는 메시징에 정착할 가능성이 큽니다.

도메인 기반 설계에서 마이크로서비스에 이르기까지 이 두 가지 접근 방식을 결합하여 크고 복잡한 문제를 해결하는 것은 비즈니스에 적합합니다.

Nick Vennaro는 기술적으로 조율된 사고 리더이며 고객을 위한 비즈니스 결과에 절대적으로 중점을 둡니다. 그는 수많은 소프트웨어 시스템과 기술에 대한 의존이 성패를 가르는 비즈니스 속성인 산업 분야에서 수많은 국가에서 일했습니다.

출처 : https://www.infoworld.com/article/3243578/from-domain-driven-design-to-microservices.html