마이크로서비스를 만들기 위한 가장 효율적인 프로세스는 실제로 동작하는 제품 중심의 반복/점진적 애자일 개발 프로세스다.
그동안 대표적인 애자일 방법론으로 스크럼과 XP 등을 많이 활용해 왔다. 특히 XP의 지속적 통합 프랙티스는 품질이 보장된 소프트웨어를 반복적이고 점진적으로 개발할 수 있게 하는 기본 토양이 된다.
또한 소트프웨어를 개발하는 생명주기로 스크럼 프로세스가 광범위하게 대충화됐다. 스크럼은 스크럼 팀이라는 조직 구성과 스프린트라는 짧은 반복 주기를 통해 피드백과 개선 작업을 촉진함으로써 단기간에 제품을 생산하고 이를 계속 발전시킬 수 있게 해준다.
스크럼이나 XP를 살펴보면 개발 문화 및 관리 프로세스에 대해서는 자세히 설명하나 설계하고 개발하는 엔지니어링 공정에 대해서는 자세히 다루지 않아 여러 오해를 낳기도 한다.
즉, 개발 문화가 미성숙된 조직에서는 애자일 활용을 할 때 설계나 관련 산출물을 아예 작성치 않고 바로 개발을 진행하는 경향이 있는데 그것은 잘못된 생각이다.
안타깝게도 애자일 문화가 국내에 유입되는 과정에서 우리나라 특유의 빨리빨리 문화와 접목되어 설계가 불필요하고 바로 개발할 수 있는 방식으로 오해 받고 있다.
아무리 간단한 소프트웨어라도 소스코드를 담을 대략의 프로그램 구조, 모듈, 명명규칙 등을 정의하고 그것들 간의 호출 관계를 생각해야 한다. 문서화하지 않더라도 이러한 고민, 사고 자체가 설계인 것이다.
XP에는 단순한 설계라는 프랙티스가 있는데, 이것은 어느 정도 개발을 시작할 수 있을 정도의 가벼운 설계를 말한다. 설계를 단순하고 간단하게 하고 바로 개발로 들어간 다음 실제로 동작하는 소프트웨어를 보면서 다시 지속적으로 리팩터링하는 방식이 더 효율적이라고 말한다.
그러나 개발 문화가 성숙치 않는 팀에 이 정도의 지침만 준다면 2-3주의 스프린트가 기존의 워터폴 일정을 단기간으로 축소화된 고된 행군의 축약 버전이 되거나 계속된 시행착오의 연속으로 다시 워터폴로 돌아가기도 한다.
또한 그 결과물인 마이크로서비스조차 잘 정리되지 않은 채 뒤죽박죽인 스파게티 코드가 될 가능성이 높다.
도메인 주도 설계(이하 DDD)는 2003년에 에릭 에반스가 쓴 책으로 객체지향 설계 및 개발의 유용한 패턴을 정리했는데, 특별히 마이크로서비스를 위한 책은 아니였으나 이후에 마이크로서비스 개발이 활성화되는 과정에서 DDD가 마이크로서비스의 설계와 개발을 위한 주요 가이드로 주목받았다.
특히 마이크로서비스의 애플리케이션 개발 측면, 응집성 있는 도메인 중심의 마이크로서비스를 도출하는 지침 및 마이크로서비스 내부의 비즈니스 로직 설계의 주요한 가이드로 사용되고 있다.
그래서 마이크로 서비스 설계 영역에서 빈번이 언급이 되며 주요 오픈 소스의 아키텍처도 DDD의 영향을 많이 받아왔다. 따라서 마이크로서비스를 도출하고 내부 구조를 설계하는 데 도메인 주도 설계 기법을 활용하는 것이 효과적이다.
DDD에는 전략적 설계와 전술적 설계라는 설계 영역이 있다. 전략적 설계는 도메인 전문가 및 기술팀이 함께 모여 유비쿼터스 언어를 통해 도메인 지식을 공유 및 이해하고, 이를 기준으로 개념과 경계를 식별해 바운디드 컨텍스트를 정의하고 경계의 관계를 컨텍스트 맵으로 정의하는 활동이다.
전술적 설계는 식별된 바운디드 컨텍스트 내의 도메인 개념인 도메인 모델을 구성하는 유용한 모델링 구성요소들을 설명한다.