우리는 꽤 큰 응용 프로그램을 가지고 있으며 DDD 지침을 따르기 위해 리펙토링하는 것을 고려하고 있습니다.DDD : 전자 상거래 샘플 외에 경계 컨텍스트로 애플리케이션을 분할하는 방법은 무엇입니까?
현재로서는 번호 매김 문제는 경계 처리 된 컨텍스트 및 컨텍스트 맵입니다. 어쩌면 나는 그것을 구제하지 않을 것이지만, 나에게 나눠하는 것은 불가능한 것처럼 보인다. 예를 들어 우리는 사용자 객체를 모든 곳에 가지고 있으며 정확히 동일한 사용자 객체입니다 : 표시 이름, ID 및 역할. 다른 예가 있습니다 : 우리는 장소의 다른 엔티티를 분류하는 데 도움이되는 CatalogItem 객체를 가지고 있습니다. Bounded Context 종속성을 도입해야합니까? 이 문제에 대한 지침이 그 지루한 전자 상거래 샘플 외에 있습니까?
처음에는 제한된 컨텍스트와 집계 루트가 DDD에서 가장 쉬운 개념처럼 보였습니다. 이는 실제 문제가있는 DDD 응용 프로그램을 실제로 구현할 때까지입니다. 여기서 쉬운 대답은 없습니다. 비즈니스 요구 사항 (확장 성, 가용성, 대기 시간, 일관성 등)에 전적으로 달려 있습니다. "올바른"솔루션은 이러한 우려를 사용자의 필요에 가장 잘 맞출 수있는 솔루션입니다. 당신이주는 예와
는 몇 가지 선택이 있습니다 :염두에 두어야 할 사실 중 하나는 쿼리 요구 사항을 "작성"하는 것과 종종 요구 사항이 매우 다릅니다. 순전히 쿼리를 위해 분리 된 컨텍스트를 갖도록 응용 프로그램 디자인을 단순화 할 수 있습니다. 이것이 적용되는 것처럼 들리면 CQRS를 살펴보십시오.
분리 된 경계 컨텍스트라고 불러야할지 확신이 없습니다 ... BC 구현에서 쿼리와 명령을 분리 할 수 있습니다. 하지만 당신은 동일한 유비쿼터스 언어를 사용하고 단지 구현 세부 사항을 담을 것입니다. (나는 방금 2010 년부터 기록을 남기겠다. – rad
알아 내면 알려주세요. ^^ –