Monilithic Application을 축소시키는 전략은 비즈니스 로직과 데이터 액세스 레이어에서 프리젠테이션 레이어를 분리하는 것이다.

일반적으로 엔터프라이즈 어플리케이션은 최소한 3가지 다른 유형의 컴포넌트들로 이루어져 있다.

프리젠테이션 레이어 - HTTP 요청을 처리하고, (REST) API나 HTML 기반 Web UI를 구현하는 구성 요소. 정교한 사용자 인터페이스를 가지고 있는 어플리케이션에서 프리젠테이션 계층은 종종 상당한 코드로 구성되어 있다.

비즈니스 레이어 - 어플리케이션의 핵심 영역이며, 비즈니스 규칙을 구현하는 구성 요소.

데이터 액세스 레이어 - 데이터베이스나 메시지 브로커와 같은 인프라 구성 요소들에 액세스하는 구성 요소

일반적으로 프리젠테이션 로직 영역과 비즈니스, 데이터 액세스 로직 사이는 분명하게 분리되어 있다. 비즈니스 계층은 비즈니스 로직 컴포넌트들을 캡슐화하는 하나 이상의 facade(진입점 역할을 하는 인터페이스)로 이루어진 대단위 API를 가지고 있다. 이 API는 monolith를 2개의 더 작은 어플리케이션으로 나눌 수 있는 자연적인 솔기이다. 한 개의 어플리케이션은 프리젠테이션 레이어를 가지고 있다. 다른 어플리케이션은 비즈니스와 데이터 액세스 로직이 포함되어 있다. 이렇게 분리한 후, 프리젠테이션 로직 어플리케이션은 비즈니스 로직 어플리케이션을 원격으로 호출하게 된다. 다음 다이어그램은 리팩토링 전후의 아키텍처를 보여주고 있다.

이 방법으로 monolith를 분할하는 것은 2가지 주요 장점이 있다. 서로간에 독립적으로 2개의 어플리케이션을 개발, 배포, 확장할 수 있다. 특히, 프리젠테이션 레이어 개발자는 사용자 인터페이스를 빠르게 반복하여 개발할 수 있다. 그리고 예를 들면, 쉽게 A|B 테스트를 수행할 수 있다. 이 접근방법의 또다른 장점은 개발한 마이크로서비스에서 호출할 수 있는 원격 API를 제공한다는 것이다.

그러나, 이 전략은 단지 부분적인 해결책일 뿐이다. 한 두개의 관리할 수 없는 monolith 어플리케이션에 대한 해결책일 공산이 크다. 나머지 monolith를 제거하기 위해서는 3번째 전략을 사용하는 것이 필요하다.