Order 클래스를 라이브러리로 묶고 Order DB를 중앙화해서 주문을 처리하는 모든 서비스가 이 라이브러리를 통해 DB에 접근하도록 만들면 어떨까요? 하지만 이 방법은 마이크로서비스 아키텍처의 핵심 원칙에 위배되어 결국 단단히 결합된 바람직하지 못한 구조가 됩니다. Order 스키마를 변경할 일이 생기면 관련 팀원들이 모두 달려들어 코드를 수정해야겠죠.

다른 솔루션은 주문 DB를 주문 서비스 안으로 캡슐화해서 다른 서비스가 주문 서비스를 통해서만 주문을 조회/수정하게 만드는 것입니다. 그러나 이렇게 하면 주문 서비스는 비즈니스 로직이 거의 없는, 빈껍데기 도메인 모델을 가진 데이터 서비스로 전락하겠죠. 두 방법 모두 신통찮아 보이는데, 다행히 DDD라는 멋진 해결책이 있습니다.

가장 좋은 방법은 DDD를 적용하여 각 서비스를 자체 도메인 모델을 갖고 있는 개별 하위 도메인으로 취급하는 것입니다. 즉, FTGO 애플리케이션에서 주문과 조금이라도 연관된 서비스는 모두 각자 버전의 Order 클래스를 가진 도메인 모델을 따로 두는 것이죠. 이런 다중 도메인 모델의 가장 좋은 사례가 배달 서비스입니다. 그림 2-11은 배달 서비스의 Order 뷰입니다. 이 서비스는 Order 대신 Delivery라는 더 적절한 이름의 모델을 사용하며, 배달 상태, 픽업 주소/시간, 배달 주소/시간 등 구조도 아주 단순합니다.

▲ 그림 2-11 배달 서비스 도메인 모델