(음식점 및 배달원의) 결제 및 (소비자의) 과금 서비스도 분리하는 것이 낫습니다.

이렇게 서비스를 거의 변하지 않는 비즈니스 능력에 따라 구성하면 비교적 안정적인 아키텍처를 구축할 수 있습니다. 나중에 비즈니스 요건이 달라져도 아키텍처를 구성하는 개별 컴포넌트는 아키텍처는 그대로 둔 채 발전(evolve, 진화)시킬 수 있습니다.

그림 2-8에 스케치한 서비스는 아키텍처를 정의한 첫 번째 버전에 불과합니다. 우리가 애플리케이션 도메인을 더 많이 알수록 서비스 역시 점점 더 정교하게 발전할 것입니다. 특히 아키텍처를 정의하는 과정에서는 각각의 핵심 아키텍처 서비스와 나머지 서비스가 어떻게 협동하는지 살피는 과정이 중요합니다. 가령 IPC가 너무 잦아 분해하는 것이 외려 비효율적이라서 서비스를 재결합하는 경우도 있습니다. 반대로 어떤 서비스는 여러 개의 서비스로 나누는 것이 더 나을 정도로 복잡해지는 경우도 있습니다. 어쨌든 여러분이 내린 결정을 재고하게 만드는 갖가지 장애 요소는 잠시 후 2.2.5절에서 다룹니다.