Raise an event or send a command?

Question

We've created a web application that is an a e-book reader. So one thing to keep in mind is that the domain is not exactly that of reading a physical book. We are now trying to gather users' reading behavior by storing information about e-book pages accessed by our users. Since this information goes to a data warehouse we thought raising an event from the bookcontroller is the right way to do it.

bus.Publish()

But we are not sure if it should be a publish or a send since there is really only one consumer to this event and that is our business intelligence team. We've also read that it is not advisable to publish from the web app (http://www.make-awesome.com/2010/10/why-not-publish-nservicebus-messages-from-a-web-application/). So now the alternative is to use bus.Send(RecordPageAccessedCommand)

But the above command does not change our application state in anyway. So is it truly a command? I have a feeling that the mistake we are making is using NServiebus's features (Publish,Send) and trying to equate it with what a command or event is.

Please let me know what the solution to this is.

Vouvray

Would it be possible to increment a counter on the book when it is accessed? The DW could then just ETL the counts later. Your app may be interested in this data to identify popular books or make suggestions. – Taking

@AdamFyles Yes, it would be possible. That is what we do currently. There are several of these events and we'd like to move to an event based non-blocking model for performance purposes. – Vouvray

Answer 1

Based on the information you provided, I would recommend "sending" to your endpoint.

Sending a command implies that the endpoint handling the message should do something. In your case, recording that the page was accessed is the thing the endpoint should do.

Publishing an event implies that you are notifying 0..n subscribers that something occurred. You could publish an event from your command handler if some other service in your system was interested in the fact that a page was accessed. The key point here is that it's not a "fact" until you've recorded it.

I've found that consumers tend to grow once data is available. Having the ability to publish an event from your command handler will make it trivial to notify new consumers without changing/risking your existing code base.

Fixate

Answer 2

The RecordPageAccessedCommand is a command as it is commanding the system to do something, in this case, record that a page has been accessed.

If I've understood your scenario correctly. A message should be sent from your controller to the "Business intelligence Team Service" telling the system to record that a page has been accessed. This service would store this information and would be the owner/technical authority of this information.

No other services should store or require this information in its pure form, they can however subscribe to events from this service, in highly contrived scenario for example, when a user reads 1000 pages the "Business intelligence Team Service" can publish an event that a 1000 pages have been read ie Bus.Publish(), which may be handled by a billing service that gives a discount for the user on their next purchase.

The data warehouse can have access to this information stored in your "Business intelligence Team Service" as it would fall under IT/OPS.

Kyrakyriako