모든 Bounded Context를 반드시 도메인 주도로 개발할 필요는 없다.
예를 들어, 상품의 리뷰는 복잡한 도메인 로직을 갖지 않기 때문에 curd 방식으로 구현해도 된다.
즉, DAO와 데이터 중심의 벨류 객체를 이용해서 리뷰 기능을 구현해도 유지 보수하는 데 크게 문제가 없다.
아래 사진과 같다.
서비스-DAO 구조를 사용하면 도메인 기능이 서비스에 흩어지게 되지만 도메인 기능 자체가 단순하면 서비스-DAO로 구성된 CRUD 방식을 사용해도 코드를 유지 보수하는 데 문제가 되지 않는다고 생각한다.
한 Bounded Context에서 두 방식을 혼합해서 사용할 수도 있다. 대표적인 예가 CQRS 패턴이다.
CQRS는 Command Query Responsibility Segregation의 약자로 상태를 변경하는 명령 기능과 내용을 조회하는 쿼리 기능을 위한 모델을 구분하는 패턴이다. CQRS 패턴을 사용하면 하나의 Bounded Context는 아래와 같이 구성 된다.
각 Bounded Context는 서로 다른 구현 기술을 사용할 수도 있다. 웹 MVC는 스프링 MVC를 사용하고 리포지터리 구현 기술로는 JPA/하이버네이트를 사용하는 Bounded Context가 존재할 수 있고, Netty를 이용해서 REST API를 제공하고 MyBatis를 repository 구현 기술로 사용하는 Bounded Context가 존재할 수 있다.
Bounded Context 단위로 독립적인 서비스로 개발하는 MSA 방식이 적합할거 같다는 생각이 들었다.
