도메인 모델과 영속성 모델을 분리하는 것이 어떤 상황에서 효율적인가 알고 싶습니다

도메인 모델과 영속성 모델을 분리했을 때 개발 생산성 측면에서 단점은 이미 잘 파악하고 계신 것 같습니다. 도메인 모델과 영속성 모델을 분리했을 때의 장점은 유지 보수성 측면에서 생각해보시면 좋을 것 같아요. 일반적으로 도메인 모델은 외부 API를 담당하고, 영속성 모델은 내부 API를 담당하게 되는데요. 그런데 외부 API는 일단 배포 후에 클라이언트가 쓰기 시작하면 바꾸기가 매우 어렵다는 특징이 있습니다. 그래서 보통 API versioning하게 되는데 하위 호환성 보장을 위해서 여러 버전을 동시에 지원해야하는 경우도 생기죠. 반면에 영속성 모델은 비즈니스 요구 사항이나 기술 의사 결정에 맞춰서 유연하게 변경되어야 하는 경우가 많습니다. 예를 들어, 해당 서비스에서 자체적으로 사용자 관리를 하고 있었는데 비지니스의 규모가 커져서 사용자 관리를 별도의 서비스로 분리하도록 아키텍쳐에 변경이 일어난다면 어떻게 될까요? 그러면 해당 서비스는 더 이상 사용자 데이터를 저장하고 있는 DB 테이블을 소유하지 않게 될 것이며 그에 따라서 도메인 모델의 변경이 불가피해질 것입니다. 자, 이런 상황에서 도메인 모델과 영속성 모델이 적절히 분리되지 않았다면 어떨까요? 해당 API를 호출하는 클라이언트에게 주는 영향을 최소화하면서 백엔드에서 이러한 내부 구조 변경을 안전하고 효과적으로 진행할 수 있을까요? 특히 마이크로소프트 아키텍쳐에서는 도메인 모델과 영속성 모델의 분리가 더 중요해질 수 있는데요. 여러 개의 서비스가 서로 복잡하게 얽혀있는 경우 하나의 서비스에서 외부 API가 깨졌을 때 연쇄적으로 다른 여러 서비스를 마비시켜 대형 장애로 이어질 수 있기 때문입니다. 정리를 해보면 도메인 모델과 영속성 모델을 분리해주면 외부 API에 영향을 주지 않으면서 내부 API를 바꿀 수 있으며, 반대로 내부 API에 영향을 주지 않으면서 외부 API도 바꿀 수 있습니다. 이러한 유연성과 확장성이 프로그램의 생명 주기가 길고, 비지니스 요구 사항이 자주 변경되는 경우 빛을 발휘할 수 있습니다. 그러나 도메인 모델과 영속성 모델을 분리하면 도메인 간 맵핑을 위한 boilderplate 코드가 늘어나서 작성할 코드가 많아지고 개발 시간이 증가하는 단점이 있기 때문에 이러한 유연성이 필요하지 않은 상황에서는 오히려 독이 될 수 있습니다. 참고로 프로젝트의 일정이 빡빡한 경우에는 개발 중에는 통합 모델을 사용하다가 나중에 운영 단계에서 모델을 분리하는 경우도 종종 보았습니다. 반대로 별 이득없이 불필요하게 모델만 분리되어 있다면 모델 통합도 고려해볼 수 있겠지요? 여러가지 이유로 환경은 수시로 변하므로 그에 맞게 전략적인 선택을 하는 것이 무엇보다 중요할 것 같습니다.