애플리케이션은 사용자의 요청을 처리하기 위해 존재합니다. 따라서 아키텍처를 정의하는 1단계는 애플리케이션 요건을 핵심 요청으로 추출하는 것입니다. 그러나 필자는 요청을 REST, 메시징 같은 특정 IPC 기술이 아닌 좀 더 추상적인 관념으로 시스템 작업을 바라보고자 합니다. 시스템 작업은 애플리케이션이 처리하는 요청을 추상한(abstract) 것입니다. 데이터를 업데이트하는 커맨드나 데이터를 조회하는 쿼리가 모두 해당되겠죠. 각 커맨드의 동작은 추상적인 도메인 모델 관점에서 정의되며, 이 또한 요건에서 도출됩니다. 결국 시스템 작업은 여러 서비스가 서로 협동하는 방식을 표현한 아키텍처 시나리오가 됩니다.

2단계는 어떻게 여러 서비스로 분해할지 결정하는 것입니다. 여러 가지 전략을 선택할 수 있습니다. 비즈니스 아키텍처 시각에서 비즈니스 능력에 따라 서비스를 정의할 수도 있고, DDD의 하위 도메인별로 서비스를 구성하는 전략도 가능합니다. 어떤 전략을 구사하든 최종 결과는 기술 개념이 아닌 비즈니스 개념 중심으로 이루어진 서비스들입니다.

3단계는 서비스별로 API를 정의하는 일입니다. 이를 위해 먼저 1단계에서 식별된 시스템 작업을 각 서비스에 배정해야 합니다. 완전한 홀로서기 작업이 구현된 서비스도 있겠지만, 다른 서비스와 협동할 수밖에 없는 작업이 구현된 서비스도 있습니다. 이때 여러 서비스가 협동하는 방식을 결정해야 하는데, 대부분 서비스에 추가 지원 작업을 두는 형태가 될 것입니다. API 구현 시 사용할 IPC(3장)도 정해야 합니다.

분해 과정에는 장애물이 많습니다. 첫째, 네트워크 지연(network latency)입니다. 서비스 간 왕복이 너무 잦아 실제로 분해할 수 없는 경우도 있습니다. 둘째, 서비스 간 동기 통신으로 인해 가용성이 떨어지는 문제입니다. 해결책은 자기 완비형 서비스(self-contained service) 개념인데, 자세한 내용은 3장에서 다룹니다. 셋째, 여러 서비스에 걸쳐 데이터 일관성을 지키는 요건입니다. 이 문제는 보통 사가(4장)로 해결합니다. 넷째, 애플리케이션 도처에 숨어 있는 만능 클래스입니다. 이런 클래스는 DDD 개념을 활용하면 어렵지 않게 제거할 수 있습니다.