For me, a “domain event” is something that’s important to the business — i.e., something relevant to the domain. So, the command model (the write side) is normally the place where domain events are raised because most of what businesses tend to care about is things that have an effect.
For the query model (read side), does the business really care that a visitor searched for a product, or clicked on a link, or opened a page? Unless you’re going to do something interesting with that event such as react to it in another context, etc. it’s quite likely that you shouldn’t be modelling things that happen in the read side as a ‘domain event’ in the same way. The right approach for most query-style things I’ve come across has simply been Google Analytics because my code doesn’t really need to care about it.
The exception to this might be if your domain is actually about search. For example, if you’re a car insurance comparison site you probably do want to think about query-style events because searching for insurance is your whole business. However, even this example might have no domain events in the query side; I’d probably model a ‘quote’ as a concept in by command model: StartQuoteCommand → QuoteWasRequested → ResultsWereReceived → SelectProductCommand → RecommendedProductWasPurchased → …
Obviously, there are some cases where you will need to do something within your own code in response to a query event — you could imagine needing to update a UI once someone has done their first three searches. Personally, I wouldn’t model this as a domain event as it will obscure things the business really cares about. This is just a quick UI optimisation so I’d just do it in some infrastructural code somewhere and not worry too much about it.
However, I can see there are cases where you do need actual domain events because you genuinely are doing something in response to them because the business really does care. An example might be that instead of simply adjusting some UI when a visitor has done some searches the marketing department says they want to start offering special promotions when a visitor has done such-and-such, or when they’ve put something in their basket and not checked out, etc. The abandoned basket case would just use domain events from a command-model (e.g., in the ‘Basket’ context/micro-service/module) but the offering of special promotions for a visitor who’s conducted certain searches is one case where I agree you have a genuine domain event coming from a query model. In such a case, I’d try and keep the nomenclature exactly like that of command models. It’s a domain event so treat it the same way.
So, in summary: unless the business really cares about it and you’re going to do something in response, it’s probably not a domain event so don’t treat it as such. FindProducts
and FindOrderHistory
are not domain events — they’re not a thing that happened which the business cares about — they’re just queries so make an API and move on. If you need to track things in the UI for analytical purposes (e.g., to optimise your UI or to see what parts of your app people are using or which products are most popular) use something like Google Analytics. If you need to do something in your UI in response to someone’s use of the UI, keep a quick and dirty log somewhere (e.g., in redis) and don’t worry about it. If you genuinely have a need to respond to things happening in the query model and you need to model that properly then you should indeed treat those things as a proper domain event and make then indistinguishable from domains events coming from your command model(s).
(PS. I prefer the terms ‘command model’ and ‘query model’ rather than write-side and read-side. I’ve used them above.)
(PPS. If you’re separating your code into modules/services/contexts then you can see where domain events are useful for communicating things between contexts. E.g., you might have a ProductCatalogue
context with a command model that raises events like ProductWasMadeAvailable
, ProductWasDiscontinued
, etc. and a query model that’s used for users to search and filter products. The query model of the ProductCatalogue
context might have lots of things going on but you may only actually make it raise domain events you know you care about, so it might raise ProductSearchWasConducted
. You might then create another context/module/service called Promotions
whose command-model would listen to ProductSearchWasConducted
and offer promotions to customers who conducted certain searches. That context might also listen to events from the Orders
context so it only offered promotions to customers who hadn’t purchased yet, or it might listen to events from the Payments
context so it only offers promotions to customers whose accounts are in credit.)
--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/9661ec63-2b3a-4e59-9e76-26f46d88005dn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/66d5d077-73e7-4376-9727-8d648eb58428n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CAKhTcw09J1JTD%3DdjAkkrj0rF8m95KR6M-x2Kjfk9pd-baCrH8A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CAKhTcw09J1JTD%3DdjAkkrj0rF8m95KR6M-x2Kjfk9pd-baCrH8A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/8dd15bf1-006b-41ac-84c6-bf0b3d6a2b13n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CAOoXFP_sYZaW%2BQ1Fem_YNTq-_toJU8v7gS3EWoUCQBggPiZBXA%40mail.gmail.com.
> Let me ask a different question, why are those data so hard to retrieve that they need such level of complexity to get a query response?This is now a system design question ? The request only reaches the API gateway. There is no service waiting behind it to send a sync. responseThere are multiple instances of the service and any one can pick it up from the message bus. So the query response event has to be put back in themessage bus and it will reach the UI.
--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CAPJBY46JQYQkyGKVd1LPqLJAZ-h7TP6-LO%3DQgeCN6HXsqUU%2BTQ%40mail.gmail.com.