모든 바운디드 컨텍스트를 도메인 주도로 개발할 필요는 없다.
바운디드 컨텍스트는 도메인 모델뿐만 아니라 표현 영역, 응용 서비스, 인프라스트럭처 영역을 모두 포함한다.
모든 바운디드 컨텍스트를 도메인 주도로 개발할 필요는 없다.
도메인 기능이 복잡하지 않고 단순하다면 서비스-DAO의 CRUD 방식을 사용해도 문제가 되지 않는다.
한 바운디드 컨텍스트에서 두 방식을 혼합해서 사용할 수도 있다.
대표적인 예가 CQRS(Command Query Responsibility Segregation)로 명령 기능과 내용을 조회하는 쿼리 기능을 위한 모델을 구분하는 패턴이다.
다음과 같이 상태 변경과 관련된 기능은 도메인 모델 기반으로 구현하고 조회 기능은 서비스-DAO를 이용해 구현할 수 있다.
각 바운디드 컨텍스트는 서로 다른 구현 기술을 사용할 수 있으며 반드시 사용자에게 보여지는 UI를 가지고 있어야 하는 것은 아니다.
웹 브라우저에서 REST API를 직접 호출해서 JSON 데이터를 가공할 수도 있고 UI 서버를 두고 바운디드 컨텍스트와 통신하는 방법도 있다.
도메인 기능이 간단한 상황이라면 오히려 도메인 주도로 개발하는 것이 불필요하다.
서비스-DAO 구조를 사용하면 도메인 기능이 서비스에 흩어지게 되지만 도메인 기능이 단순해 유지 보수에 문제가 되지 않는다고 생각한다.
도메인 주도 개발이 필요한 상황에 맞춰 적절하게 사용하면 좋을 것 같다.