소프트웨어 개발의 역사에서 모듈화의 중요성은 예전이나 지금이나 한결같다. 모듈화의 근본적 가치는 각 모듈을 기능적으로 응집성 높게 만들고, 기능이 다른 타 모듈 간의 의존도를 낮추는 것이다.
마찬가지로 마이크로서비스 설계에서의 가장 중요한 관심사도 어떻게 기능적으로 응집성 있는 마이크로서비스를 도출하고 타 서비스 간의 의존도는 낮출것인가다. 또한 마이크로서비스의 내부 구조를 구성하는 각 요소들도 역할별로 모듈화 돼야 한다.
즉, 역할별로 모듈화된다는 말은 각 역할이 분명하고 응집성 있으며 서로 의존성이 낮은 모듈들이 모여 마이크로서비스를 이루며 이 마이크로서비스는 다른 마이크로서비스와 의존성이 낮아야 한다.
다른 방식으로 표현하자면 마이크로서비스를 구성하는 각 요소들이 모두 소프트, 즉 유연해야 한다는 말과 같은데 DDD의 전략적 설계와 전술적 설계가 이를 위한 적절한 가이드를 준다. DDD를 중심으로 마이크로서비스를 도출하고 설계하는 방안들을 아래에서 살펴보자
마이크로서비스가 비니지스의 변화 속도를 지원하면서 독립적으로 변경 및 배포되려면 각 마이크로서비스가 다른 서비스와 의존하지 않게 도출해야 한다. 따라서 시스템의 어떤 비즈니스 기능들을 묶어서 독립적인 마이크로서비스로 도출한 것인가를 결정하는 것인 매우 중요하다.
마이크로서비스를 식별하는 가장 쉬운 방법은 경험적인 원칙을 적용하는 것이다. 크리스 리처드슨은 마이크로서비스 패턴에서 비즈니스 능력에 따라 서비스를 식별할 수 있다고 말한다. 또한 비지니스 능력은 비즈니스 가치를 생산하기 위해 하는 일이라고 정의하며, 곧 조직이 하는 일이라고 말한다.
다시 말해, 각 도메인에서는 비즈니스가 규정하는 일하는 방식과 조직, 부서 체계가 이미 정의돼 있고, 이러한 부서는 이미 업무 처리에서의 응집성을 가지고 있어 타 부서와의 의존도는 낮을 것이다.
이처럼 비즈니스 부서가 가진 역할, 처리 능력을 체계적으로 분해할 수 있으며, 보통 이를 업무 기능 분해라고 한다. 업무 가능 분해는 업무 흐름에 따라 업무를 최상위에서 하위까지 크기로 분리하고 수행하는 일들을 체게적으로 정렬한다. 그 결과 특정부서가 처리하는 업무 역할과 비슷해진다
대, 중 , 소의 분류 중 어떤 레벨을 서비스로 식별해야 하는지 고민이 될 수도 있지만 쉽고 직관적으로 도출할 수 있다.
그렇지만 이러한 방식은 전체적인 대략의 비즈니스를 이해할 때는 유용하나 서비스 간의 관계 파악이나 구체 기능과 연관된 서비스가 관리할 독립적 데이터를 식별하기에는 미흡하다.
비즈니스 능력에 따른 서비스 도출 한계를 보완하기 위해 DDD의 전략적 설계를 적용할 수 있다. 마이크로서비스는 각 저장소를 독립적으로 보유하고, 각 데이터는 다른 서비스에서 직접 참조해서는 안 되는 특성이 있다. 이러한 특성이 기존 SOA 방식과는 다르게 서비스를 독립적으로 수정 및 배포 할 수 있는 장점으로 작용 했다.
따라서 마이크로서비스를 도출할 때 서비스가 소유권을 가진 데이터를 독립적으로 식별하는 것이 중요하다. 서비스가 보유한 기능에 의해서만 접근 가능한 데이터를 파악할 필요가 있다.
기능 분해 방식은 서비스가 소유해야 할 데이터 식별에 적합하지 않으며, 기능과 데이터가 분리되고 하나의 통합 데이터가 여러 기능에서 사용되도록 모델링 되는 방식이다. 따라서 비즈니스를 처리하는 기능과 그 기능에 영향을 받는 데이터가 분리되는 경향이 있다.
도메인 모델은 각 업무에 특화된 유비쿼터스 언어로 정의되며 그 업무에 특화된 개념으로 구성된다. 아래 그림과 같이 도메인 모델을 소유한 바운디드 컨텍스트 중심으로 마이크로서비스를 도출하는 가이드로 사용횔 수 있다.