A common story we often hear is related to searching for information. This is a powerful capability to provide through your technology services as the user is keen to interact with your offering and the richer and performant it is, the more value the consumer draws from this. Google it!
When analysing the search story, we may find that the search is within a single domain or aggregate information from different sources. The key is to recognise when this is the case because we can then model the partnership (upstream-downstream, conformist etc) and recognised that the search response is a hybrid model
Let us look at samples for both use cases and see if can model these
Search within a domain
When this is in a single domain the domain service is quite simple to model i.e we work within construct of our domain and do not need to consider external concepts. The example below shows a “service” that does not have the data but then uses the data provider (database or service) to request and get results back
Key things to note in these stories when modelling from search a domain story are
- recognise that our search request maps across some or all the attributes of the collection of entities within a searched domain
- notice that the search representation of a domain entity is not the domain entity (as the question to your domain expert – “do you need everything coming back?”)
- you need some technical magic which a domain expert may or may not call out –
- the identity (ID) of each element to later get details by that identifier
- a search context id so that the service or the data provider can optimise for multiple requests for the same search query (e.g. different pages for the same search)
- the page size of that you know how much to return in each response
- the number of pages, so that you user knows that this is a small or large set and can navigate
Aggregate search
Contrary to the search within a single domain you may discover as you probe your domain experts further (or they may add a new requirement later) that your service now needs to add more value and make things interesting by pulling results from different sources
Some of the heuristics I use for detecting domain boundaries when listening to stories are when the domain expert changes or system of record changes or the source becomes external. Applying to an aggregated search context, if we are within the same business domain but cross solution contexts or across totally different business domains then it is best to think of a boundary existing between the search service and the data providers
If there is such a boundary then from a strategic DDD perspective the following applies:
A. The search service is downstream and the providers are upstream and there is a dependency chain. This applies to the teams building and maintaining these services
B. The search services’ context and the providers contexts are in a partnership
C. This partnership can be a shared kernel (bad) if the search service uses the database of the provider directly. This means there are one or more members in the search service team that know about the inner workings of the provider making it hard for the provider systems to change
D. This partnership is as-a-service (OHS/PL) if the provider provides a Query API or Events and Query API. This means that there must be a contract (for API and Events), this contract must specify service SLAs and more importantly the consumer needs to implement error handling especially if the service is overloaded. The provider must protect itself or monetize its value from one or more such consumers that use it as an aggregator
E. This partnership is conformist if the search service conforms to the model of provider. This can be bad in the long term especially if the provider specification changes. Consider implementing an anti-corruption layer (ACL)
F. If the service provider eagerly constructs its model to service the consumer (the search service) then it becomes the a Customer Supplier relationship, making the search service powerful i.e. it can always ask the supplier to change its service’s data model to suit its needs
Also from a Tactical DDD and aggregate modelling perspective the following applies:
A. The search model references external models in different context – i.e. uses some of the attributes
B. The search model references the external models as a referenced entities – i.e. does not manage their lifecycle
C. The search model may reference these external results as Value Object – i.e. it always needs an identifier to get the details by ID later. In some cases these may not be IDs but Monikers (e.g. Address search API) and short-lived. This would make caching the search results problematic in the long run (if the monikers expire)
D. The search model also includes attributes related to the search (search id, page size, page number etc)
E. You can model a search a generic service (I have reasoned that way) but then you end up building an anemic model and a shallow service with increasing dependency chain (as more providers are added etc). It is best to reason about a search with a specific business domain name and model the validation, rules etc for processing the results
Consistency or Availability?
One of the design heuristics I tend to apply when building any service is to ask if this solution needs consistency i.e. the information as it is now in the system of record, or do we need availability i.e. the information can be stale but the service is highly available or can tolerate network failure (between the consumer and service provider)
In the search use case, I tend to ask the domain experts about the nature of the arrows from the search service to the providers – “is it happening in the same transaction / context as the actor’s request or does this happen in the background?”
If they respond with “same context” then I worry a bit as this may not scale (welts on my back from previous experience), ask politely if there are options to tolerate slightly stale information in light of service performance and scalability. Aggregating in real-time is pushing your SLAs down to the provider making your solution slower and difficult to scale
Look to use as event-driven approach where the search service is a consumer of the provider domain events and reacts to those events to query what it needs for the search
Cache aside or Cache as SOR?
The other consideration we need to make with searching is whether we keep the results of the cache pre-loaded (cache as SOR) or if we load it after the first query (cache-aside)
This depends on the type of storage you have as the search request space can be quite large (try to cache a type-ahead search) and I would generally recommend using cache-aside for the search which is populated after the first call and is short lived
Wrapping things up!
Searching is a common story when domain storytelling as there are lots of business models out there that need this capability. It is quite often the case that a value-added search is across multiple domain and requires crafting this with care to ensure the service can change independently of the providers, scales well to new business needs and is performant without needing specialised infrastructure
Alok Mishra 