DDD에서 파일 액세스를위한 Bounded Context를 정의 할 가치가 있습니까?
저는 편집기를 파일에서 문서로 열고, 저장하고, 저장하는 데스크톱 애플리케이션으로 디자인하고 있습니다. 사실 매우 일반적인 것입니다.
비즈니스 규칙에 대한 경계 컨텍스트가 이미 있습니다.
순진하게도 엔티티를 ID로 재수 화하고 파일 액세스 및 관리를 통해 리포지토리를 구현하는 데 사용되는 파일의 경로를 지정하고 싶습니다.
그러나 내 응용 프로그램에서 파일 측면을 관리하는 올바른 방법이 아니라는 느낌이 있습니다.
그렇다면 파일 관리 전용 Bounded Context를 디자인하는 것이 흥미로울 것이라고 생각하십니까?
DDD와 파일 관리를 혼합 한 이러한 응용 프로그램의 예가 있습니까?
대부분의 예제는 리포지토리를 통한 데이터베이스 액세스를 보여 주며 지금까지 그것에 대해 아무것도 찾을 수 없었습니다.
답변
내가 이해했듯이 파일 관리는 비즈니스 도메인의 일부가 아니므로 전용 경계 컨텍스트는 내 의견으로는 의미가 없습니다.
파일 경로를 기본 문자열 유형으로 집계에 대한 식별자로 사용하는 것이 불편하다는 것을 어떻게 든 이해할 수 있습니다. 따라서이 식별 측면을 캡슐화하고 도메인 모델과 함께 작동하는 클라이언트 코드에서 추상화하는 DocumentId와 같은 값 개체 를 만드는 것이 좋습니다 . 나머지 저장소 구현은 데이터베이스에 콘텐츠를 저장 한 것과 동일하게 작동합니다. 도메인 계층에서 리포지토리 인터페이스를 사용하고 리포지토리 구현은 인프라 계층에 있습니다.
책에서 나는 경계가있는 맥락을 충분히 통합 된 개발 영역으로 이해하여 사람들이 이름으로 표현되는 개념에 동의 할 수 있습니다. 과중한 의사 소통과 조정없이 문제의 별도 측면에서 작업하는 팀간에 분할이 발생하는 것 같습니다. ( 이 질문에 대해서도 설명합니다)
설명하는 문제가 여러 팀에서 처리되어야하는 것 같지 않습니다. Generic Subdomain 형식으로 파일 관리를 별도의 모듈로 이동할 수 있습니다 .