2013-05-14 2 views
0

나는 파란색 책을 거의 읽지 않고 빨간색 책 (도메인 구현 디자인 구현)의 처음 3 장을 읽었습니다. 두 가지 질문이 있습니다.여러 개의 제한된 컨텍스트 및 프로젝트 구조가있는 하위 도메인

(1) 하위 도메인에 둘 이상의 바운드 컨텍스트가있을 수 있습니까? 나는 특히 하위 도메인을 정렬/인벤토리와 겹치게하는 도메인 기반 디자인 구현 (Implementing Domain Driven Design) 책의 예를보고 있습니다. 책을 읽지 않았다면 죄송합니다.하지만 두 경계 상황이 겹치는 것이 좋습니다.

(2) 프로젝트 솔루션 구조를 구성하려면 어떻게해야합니까? (.NET을 사용하고 있습니다) 실제 프로젝트를 볼 수있는 예가 있습니까? 폴더, 즉 하위 도메인, 코어 도메인, 일반 도메인을 생성하고 그 아래에 모듈을 지정해야합니까? 양파/육각형 레이어가 제 위치에 있음을 보여주기 위해 내 구조를 정의하는 최선의 방법에 대해 고심하고 있습니다.

미리 감사드립니다.

답변

1
  1. 예. 도메인은 여러 하위 도메인으로 구성되며 (충분히 복잡한 경우) 각 도메인은 사실 제한된 컨텍스트 그룹입니다. 도메인 자체는 App 관점에서 경계 컨텍스트 (BC)로 간주 될 수 있습니다. BC는 고유 한 모델이 아니라 비즈니스 개념의 특정 표현을 포함한다는 의미입니다. 따라서 여러 개의 BC로 책 정의를 가질 수는 있지만 각각의 정의는 전체 세부 사항에서 ID까지 약간 다릅니다. 예를 들어 재고에서의 책이 판매에서의 책과 다릅니다. BC가 개념을 이해하는 방법은 중요합니다. 결과 모델은 다른 BC의 모델과 동일한 이름을 가질 수 있지만 해당 BC에서만 유효합니다. 그러나 그것이 바로 네임 스페이스가 필요한 것입니다.

  2. 레시피가 없으므로 모든 사람이 자신의 프로젝트를 구조에 맞게 구조화합니다. 하지만 대부분의 경우 Domain Project와 UI, Persistence, Infrastrcuture 프로젝트가 하나 이상있을 것입니다. 최고의 구조는 앱과 개발자의 생각에 달려 있다고 생각합니다. 내가하는 일이 내가하는 최적의 방식이 아닐 수도 있습니다. 간단히 말해서, 앱을 구조화하는 것이 좋습니다.

관련 문제