도메인 기반 디자인의 검색 컨텍스트

Question

스택 오버플로와 같은 웹 사이트의 검색 컨텍스트를 도메인 기반 디자인에 따라 어떻게 모델링 할 수 있습니까?

내 도메인에서 질문, 답변, 질문 모음과 같은 세 가지 유형의 항목이 있다고 가정 해 보겠습니다. 검색 문자열을 받아들이고 일치하는 질문, 답변 및 태그를 반환하는 방식으로 검색 컨텍스트를 모델링해야합니다.

는 등 집계

일치하는 알고리즘은 가정 할 수있다

내가 검색 맥락에서, 검색은 검색을 수행하거나 일부 개체가있을 수 있습니다 단지 주차 대행 서비스가 될 것입니다, 이해 할

입니다 것을 간단한 SQL 같은 쿼리.

Answer 1

아마도 검색 경계 된 문맥에 대해 DDD 전술 패턴의 전체 배열을 필요로하지 않을 것입니다. 검색 기본 설정을 저장하거나 검색 템플리트를 작성하려고 계획하는 경우를 제외하고 아마도 심지어 매우 혼란 스러울 것입니다.

검색 컨텍스트가 다른 BC의 데이터를 인덱싱하거나 액세스하는 방법을 디자인하는 것은 더 복잡한 문제 일 수 있습니다.

Answer 2

검색어 서비스에서 검색을 구현해야합니다. 당신은 귀하의 경우와 같은 명령을 사용하여 모델을 업데이트 할 때 때문에

CQRS은 DDD와 정말 잘 맞는 :

AnswerToQuestionCommand, PostNewQuestionCommand 등

이러한 명령은 응용 프로그램 서비스로 전송된다

이는 엔티티를 업데이트하고, 엔티티는 6 각형 아키텍처에서 인터셉트되어 검색 인덱스를 업데이트하는 DomainEvent를 보냅니다. 6 각형 아키텍처에서이를 수행 할 수 있습니다. 동일한 트랜잭션에서 인덱스를 유지 관리하는 전용 서비스를 호출합니다. 인덱스가 예를 들어 업데이트 된 경우 엔티티가 지속되는 것으로 간주합니다. 나는이 길로 갈 것이다. 당신은 당신이 쿼리 서비스를 통해 이동 등 질문, 답변, 쿼리해야하는 경우 여기

봄 @TransactionalEventListener

@Component 
public class ProjectRenamedListener { 

    @Value("${spring.jpa.properties.hibernate.search.default.indexBase:target}") 
    private String indexBase; 

    private final Logger logger = LoggerFactory.getLogger(ProjectRenamedListener.class); 

    @TransactionalEventListener 
    public void projectRenamed(final ProjectRenamed event) { 

     try (final StandardAnalyzer analyzer = new StandardAnalyzer(); 
      final Directory directory = NIOFSDirectory.open(Paths.get(indexBase, ProjectData.class.getName())); 
      final IndexWriter writer = new IndexWriter(directory, new IndexWriterConfig(analyzer))){ 

      final Document document = new Document(); 
      document.add(new StringField("project_id", event.projectId().identity(), Field.Store.YES)); 
      document.add(new StringField("tenant_id", event.tenant().identity(), Field.Store.YES)); 
      document.add(new TextField("name", event.name(), Field.Store.YES)); 
      writer.updateDocument(new Term("project_id", event.projectId().identity()), document); 
     } catch (IOException e) { 
      logger.warn("Unable to update index for project name.", e.getMessage()); 
     } 
    } 
} 

와 샘플입니다. 색인을 요청하고 클라이언트로 리턴 할 엔티티를로드하십시오.

이 기능의 장점은 수정하고 쿼리 할 때 동일한 개체 일 필요가 없다는 것입니다. 코드 복제로 인해 시작할 때 약간 이상하게 들리지만 장기간에 걸쳐 발생하는 읽기/질의 작업 사이의 결합이 빠르며 빠르지 만, 많이 발생해서는 안되는 쓰기 작업 그리고 특별히 ont는 매우 빠르다.

@PreAuthorize("hasAuthority('Administrator')") 
public Page<ProjectData> searchProjectsData(
     final String tenantId, 
     final String queryText, 
     final Pageable pageable) { 

    if (!StringUtils.isEmpty(tenantId)) { 
     return this.searchProjectsDataOfTenant(tenantId, queryText, pageable); 
    } 

    final StandardAnalyzer analyzer = new StandardAnalyzer(); 
    final QueryBuilder builder = new QueryBuilder(analyzer); 
    final Query query = builder.createPhraseQuery("name", queryText); 

    try { 
     final IndexReader reader = DirectoryReader.openIfChanged(this.directoryReader); 
     final IndexSearcher searcher = new IndexSearcher(reader); 
     final TopDocs documents = searcher.search(query, pageable.getPageSize()); 
     return this.fetchProjectsData(searcher, documents, pageable); 
    } catch (IOException e) { 
     throw new RuntimeException(String.format("Unable to search project for query: %s", queryText), e); 
    } 
}