Search Context in Domain Driven Design - domain-driven-design

Question

How can a search context for website like stack overflow be modelled following Domain driven design?
Let's say in my domain, I have three type of entities as Questions, Answers, Tags of Questions.
I have to model a search context in a way that it accepts a search string and return matching questions, answers and tags.
I want to understand that, In search context, is search going to be just a ddd-service which will perform search or can there be some entities, aggregates etc.
It can be assumed that matching algorithm is simple sql like query.

Answer 1

You need to implement the search in a Query Service.
CQRS fits really good with DDD because when you want to update the model you use commands, such as in your case:
AnswerToQuestionCommand, PostNewQuestionCommand, etc.
These commands are sent to your application service, which updates the entity, which in turn send a DomainEvent, which is intercepted in the hexagonal architecture and updates the search index. You can do it in the hexagonal architecture: by calling a service dedicated to maintain the index in the same transaction. You consider an entity persisted if the index has also been updated for instance. I would go this way.
Here is a sample with Spring #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());
}
}
}
When you need to query your Questions, Answers, etc. you go through a query service. You ask the index, and load the entities that you want to return to your client.
The beauty of this is that it does not have to be the same object when you modify it and query it. It sounds a bit wierd when you start because of the code duplication but on the long run its clearly superior solution as you have no coupling between reading / query operation which occurs a lot and should be fast, and writing operation which should not occur a lot and does ont have to be specially super fast.
I would suggest the approach of Vaughn Vernon on query services (https://github.com/VaughnVernon/IDDD_Samples), I used lucene on my part for a query service, here is some code:
#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);
}
}

Answer 2

You probably don't need the whole array of DDD tactical patterns for a Search bounded context, no. Except if you're planning on storing search preferences or creating search templates, maybe - even then, it seems very CRUDish.
Designing how the search context indexes or accesses the data from other BC's can be a more complex matter, though.