이처럼 각 도메인 모델의 Order 클래스는 Order라는 동일한 비즈니스 엔터티의 상이한 측면을 나타냅니다. 상이한 서비스의 상이한 객체 간 일관성을 유지하는 일은 FTGO 애플리케이션의 몫입니다. 가령 주문 서비스는 소비자 신용카드를 승인 후, 반드시 주방 서비스의 Ticket 생성을 트리거(trigger, 다른 컴포넌트가 주어진 액션을 취하도록 신호)해야 합니다. 마찬가지로 음식점이 주방 서비스를 통해 주문을 거부하면 주문 서비스는 해당 주문을 반드시 취소한 후 이미 승인된 신용카드 내역을 취소해야 합니다. 이런 서비스 간 일관성은 이벤트 주도 메커니즘인 사가를 활용해서 유지할 수 있는데, 자세한 내용은 4장에서 설명합니다.

기술적인 문제 외에도 도메인 모델을 여러 개 두면 UX(User Experience, 사용자 경험) 구현에도 영향이 있습니다. 애플리케이션은 그 자체가 도메인 모델인 UX와 각 서비스의 도메인 모델을 서로 변환해야 합니다. 가령 소비자가 조회한 주문 상태는 여러 서비스에 저장된 Order 정보에서 비롯된 것입니다. 이런 변환 작업은 보통 API 게이트웨이(8장)로 처리합니다.