◆ Micro Service 설계
▶ 소프트웨어 개발의 역사에서 모듈화의 중요성은 예전이나 지금이나 한결같은데 모듈화의 근본적 가치는 각 모듈을 기능적으로 응집성 높게 만들고(high cohesion) 기능이 다른 타 모듈 간의 의존도를 낮추는 것(low coupling)
▶ 마이크로서비스 설계에서의 가장 중요한 관심사도 어떻게 기능적으로 응집성있는 마이크로서비스를 도출하고 타 서비스 간의 의존도는 낮출 것인가 하는 것이고 마이크로서비스의 내부 구조를 구성하는 각 요소들도 역할별로 모듈화 돼야 하는데 역할 별로 모듈화 된다는 말은 각 역할이 분명한 응집성 있고 서로 의존성이 낮은 모듈들이 모여 마이크로서비스를 이루고 이 마이크로서비스는 다른 마이크로서비스와 의존성이 낮아야 한다는 의미
▶ 다른 방식으로 표현하면 마이크로서비스를 구성하는 각 요소들이 모두 소프트 즉 유연해야 한다는 말과 같은데 언급한 바와 같이 DDD의 전략적 설계와 전술적 설계가 이를 위한 적절 한 가이드를 줌
▶ 비즈니스 능력에 근거한 도출
● 마이크로서비스를 식별하는 가장 쉬운 방법은 경험적인 원칙을 적용하는 것
● 크리스 리처드슨은 마이크로서비스 패턴에서 비즈니스 능력(capability)에 따라 서비스로 식별할 수 있다고 말하고 비즈니스 능력은 비즈니스 가치를 생산하기 위해 하는 일이라고 정의하며 곧 조직이 하는 일이라고 말함
● 각 도메인에서는 비즈니스가 규정하는 일하는 방식과 조직, 부서 체계가 이미 정의 돼 있고 이러한 부서는 이미 업무 처리에서의 응집성을 가지고 있고 타 부서와의 의존도는 낮을 것
● 비즈니스 부서가 가진 역할, 처리 능력을 체계적으로 분해할 수 있으며 보통 이를 업무 기능 분해라고 하는데 업무 기능 분해는 업무 흐름에 따라 업무를 최상위에서 하위까 지 대, 중, 소의 크기로 분리하고 수행하는 일들을 체계적으로 정렬하면 특정 부서가 처리하는 업무 역할과 비슷해짐
● 그렇지만 이러한 방식은 전체적인 대략의 비즈니스를 이해할 때는 유용하지만 서비스 간의 관계를 파악하거나 서비스의 구체 기능과 연관된 서비스가 관리할 독립적인 데이터를 식별하기에 는 미흡하기 때문에 이를 보완할 대책이 필요
▶ DDD의 바운디드 컨텍스트 기반 도출
● 비즈니스 능력에 따른 서비스 도출 한계를 보완하기 위해 DDD의 전략적 설계를 적용할 수 있는데 마이크로서비스는 각 저장소를 독립적으로 보유하고 각 데이터는 다른 서비스에서 직접 참조해서는 안되는 특성이 있는데 이러한 특성이 기존 SOA 방식과는 다르게 서비스를 독립적으로 수정 및 배포할 수 있는 장점으로 작용
● 마이크로서비스를 도출할 때 서비스가 소유권을 가진 데이터를 독립적으로 식별하는 것이 중요
● 서비스가 보유한 기능에 의해서만 접근 가능한(캡슐화) 데이터를 파악할 필요가 있는 것이지만 기능 분해 방식은 서비스가 소유해야 할 데이터 식별에 적합하지 않고 기능과 데이터가 분리되고 하나의 통합 데이터가 여러 기능에서 사용되도록 모델링되는 방식이므로 비즈니스를 처리하는 기능과 그 기능에 영향을 받는 데이터가 분리 되는 경향이 있음
● DDD에서는 이처럼 데이터를 기능과 분리해서 식별하지 않고 문제 영역인 하위 도메 인마다 별도의 도메인 모델로 정의
● 도메인 모델은 각 업무에 특화된 유비쿼터스 언어로 정의되고 그 업무에 특화된 개념으로 구성하는데 독립적인 팀이 자율적으로 마이크로서비스를 개발 및 운영하는 마이크로서비스 의 개념과 매우 잘 어울렸고 도메인 모델을 소유한 바운디드 컨텍스트 중심으로 마이크로서비스를 도출하는 가이드로 사용될 수 있음
◆ DDD에서의 설계
▶ 클라우드 와 마이크로서비스 아키텍처 적용을 통해 얻을 수 있는 장점인 독립적 개선과 배포, 장애 격리, 장애 발생 시 빠른 재실행을 가능하게 하려면 마이크로서비스를 응집성 있게 식별하는 것이 매우 중요
▶ DDD의 전략적 설계에서는 비즈니스 응집성이 있는 컨텍스트를 구분하고 이를 바운디드 컨텍스트라 하는데 이 단위가 마이크로서비스를 식별하기 위한 훌륭한 단위가 될 수 있음
▶ 전략적 설계를 통해 식별된 마이크로서비스의 내부 구조를 정의하고 상세히 설계하기 위해 DDD의 객체 설계 기법인 전술적 설계를 사용할 수 있음
▶ 비즈니스 변화에 빠르게 대응하기 위해 클라우드 와 마이크로서비스 아키텍처를 적용했다면 비즈니스의 변화 못지 않게 빠르게 변화하는 구현 기술에도 적시에 대응할 수 있는 유연한 애플리케이션 아키텍처가 필요
▶ 비즈니스 변화에 빠르게 대응하기 위해 클라우드 와 마이크로서비스 아키텍처를 적용했다면 비즈니스의 변화 못지 않게 빠르게 변화하는 구현 기술에도 적시에 대응할 수 있는 유연한 애플리케이션 아키텍처가 필요
▶ 도메인 과 서브 도메인
● DDD에서는 하나의 큰 도메인을 전략적으로 중요한 것들을 찾아 중요도에 따라 도메인을 나누고 각 도메인을 각각 하나씩 해결하는 방법을 기본으로 삼음
● 이 방법을 사용하려면 알아야 할 몇 가지 개념이 있음
● 시스템 개발을 통해 해결하고자 하는 비즈니스 도메인을 논리적으로 구분되는 개념으로 나누면 문제가 되는 영역을 쉽게 이해할 수 있는데 많은 개념들이 하나로 엮인 복잡한 비즈니스 도메인을 논리적으로 구분되는 여러 개의 하위 영역으로 분리해야 한다는 뜻으로 이렇게 분리된 하위 도메인을 서브 도메인이라고 함
● 서브 도메인은 중요도에 따라 핵심 서브 도메인, 지원 서브 도메인, 일반 서브 도메인의 세 가지 유형으로 나눔
◎ 핵심 서브 도메인은 다른 경쟁자와 차별화를 만들 비즈니스 영역이기 때문에 기업의 프로젝트 목록에서 높은 우선 순위를 갖는 영역 이자 소프트웨어 개발에서 전략적으로 가장 큰 투자가 필요한 영역
◎ 두 번째로 지원 서브 도메인은 비즈니스에 필수적이지만 핵심은 아닌 부분으로 볼 수 있으나 핵심 도메인을 성공시키기 위해서는 반드시 필요한 영역으로 핵심 서브 도메인 다음으로 중요한 영역
◎ 마지막으로 일반 서브 도메인은 비즈니스적으로 특화된 부분은 아니지만 전체 비즈니스 솔루션에는 필요한 부분으로 기존 제품을 구매해서 대체할 수 있음
◎ 아마존 쇼핑몰에서는 한 번이라도 검색하거나 장바구니에 담았거나 이전에 구매했던 상품과 같은 상품을 추천해서 구매자의 소비를 촉진하는데 아마존은 이러한 추천 영 역을 핵심 서브 도메인으로 정하고 다른 쇼핑몰과 차별화를 위해 더 많은 역량을 투입했을 것이며 국내에서는 쿠팡이 다른 쇼핑몰과 다르게 로켓 배송이라는 영역을 핵심 서브 도메인으로 선정해서 전략적인 투자를 통해 다른 쇼핑몰과의 차별화된 배송 전략으로 성공했으리라 생각해 볼 수 있음
◎ 전략적 설계는 마이크로서비스를 도출하는 방법이자 비즈니스상 전략적으로 중요한 것을 찾아 중요도에 따라 일을 나누기 위해 사용할 수 있는데 이러한 전략적 설계를 수행하기 위해 반드시 알아야 할 중요한 개념 두 가지가 있는데 첫 번째는 도메인의 주요 개념을 정의하고 도메인 간의 경계를 식별하는 바운디드 컨텍스트이고 두 번째는 도메인의 모든 구성원이 공통으로 사용하는 유비쿼터스 언어(Ubiquitous Language)
댓글