7
저는 처음 "실제"DDD 응용 프로그램을 만들고 있습니다.DDD. 사용자가 구성 할 수있는 설정은 어디에 속합니까?
현재 내 클라이언트는 내 도메인 계층에 대한 액세스 권한이 없으며 명령을 실행하여 도메인에 대한 변경을 요청합니다.
그런 다음 간단한 CQRS와 같은 정보를 표시하기위한 별도의 (평평한) 읽기 모델이 있습니다.
지금 구성이나 사용자가 구성한 설정에 대해 작업하고 있습니다. 예를 들어 블로그 애플리케이션을 사용하는 경우 설정은 블로그 제목 또는 로고 일 수 있습니다.
간단한 키 값 쌍 콜렉션을 기반으로 강력한 유형의 구성 객체 (예 : BlogSettings)를 빌드하는 일반 구성 빌더를 개발했습니다. 이 구성 객체가 내 도메인의 일부인지 여부에 따라 달라집니다. 클라이언트와 서버에서 액세스해야합니다.
이러한 구성 개체가 포함 된 "공유"라이브러리를 만드는 것이 좋습니다. 이것이 올바른 접근 방법입니까?
마지막으로 이러한 구성 설정을 저장하는 코드는 어디에 있습니까? 쉬운 해결책은 내 Domain.Persistence 프로젝트에이 코드를 넣는 것이지만, 도메인에 속하지 않으면 실제로 거기에 있어야합니까? 그들이 강력하게 형식화 된 유비쿼터스 언어, 즉 'BlogSettings'를 기반으로 모델링하는 경우
감사합니다,
벤
별도의 "구성"또는 "설정"경계 컨텍스트가있을 수 있습니다. 이것은 물리적 분리가 아니라 논리적 분리입니다. 따라서 다양한 기술 (클라이언트 대 서버)을 사용하여 컨텍스트에 대한 액세스를 제공 할 수 있습니다. 그러나 그렇게하는 모든 코드는 컨텍스트에 속합니다. –
@YvesReynhout 이것이 우리가 상호 작용하는 구성 컨텍스트를 가지면서 끝난 라우트입니다. 그러나 우리는 구성 객체를 공유했습니다.이 경우 분리는 불필요한 코드 중복을 유발했을 것입니다. –
아,하지만 논리적으로 분리해도 코드가 중복되지 않습니다. 바운드 컨텍스트가 코드를 담당한다는 것을 의미합니다. 바운드 컨텍스트의 코드가 전개되는 방법은 그 사실에 완전히 직각입니다 (다른 바운드 컨텍스트의 코드와 함께 프로세스 내에서 완벽하게 호스팅 될 수 있음). –