Let's imagine I have a hot observable that is a source of weather events. This source is a socket connection to a remote server that provides information about the weather in my current location.
That remote server can also send me events about other related topics as traffic, extreme weather warnings, etc... if I send a command to indicate this desire.
How can I model this with Reactive Extensions without creating coupling between observable and observer?
The idea is that when I subscribe ExtremeWeatherWarnings (observer) to my WeatherServerConnection (observable), somehow the first issue some commands to the second, so it enables the subscription.
I have tried to implement an special interface in the observer, that tells the observable the commands it needs to execute in subscription and unsubscription, but it does not work in the moment I put a Where in the middle because LINQ RX is wrapping the observable, and that wrapper does not implement any interface.
I can also require an instance of the WeatherServerConnection object on the ExtremeWeatherWarnings constructor, but that will create coupling and I would like to avoid that.
Cheers.
If your observables is designed to send generic messages, and your observer is design to translate them, you also need a way of indicating to the producer what kinds of messages you're interested in.
One way to do this is "requesting an observable".
ObservableWeatherSource GetNotifications(WeatherWarnings warningTypes, string location);
Another way might be to lazily indicate what notifications you're interested in.
ObservableWeatherSource source = GetWeatherSource();
source
.Where(x => x.WeatherWarningType === WeatherWarnings.Rain)
.Subscribe(new WeatherObserver());
source.ExpressInterestIn(WeatherWarnings.Rain, "San Francisco");
Or, possibly, you might be interested in writing a specialized query language for weather. You could probably do this through the IQbservable and a query provider, but I have little knowledge of this area of Rx.
It all depends on how you think of your observables.
If it's a stream of events independent of the observers, you can just expose the observable to anyone that want's to subscribe to.
That was the approach I followed on my reactive GeoCoordinateWatcher. The wrapped GeoCoordinateWatcher class will generate events independent of the subscription.
For the reactive Geolocator I chose to follow the same approach. But because the Geolocator needs parameterization to produce events, I could have chosen to implement an observable factory.
The bottom line is (as #Christopher said) that you send commands to something that exposes an observable and not to the observale itself.
You migth do something like sending commands to the observable by applying Rx operators. If those filters are to be applied remotely, you can implement (as #Christopher said) an IQbservale instead.
Related
We are writing a C# application to process events/ messages from a student application system.
The web based portal sends events/ messages to a queue table. We dequeue these and, based on message type, want to process each event.
Example events are ‘applicationSubmitted’, ‘applicationUpdated’, ‘offerAccepted’ etc.
There are quite a number of different event/ message types. We want to use the CQRS pattern, but would value input on how commands would be structured. Would you create a command for each event/ message type? Would you use a command factory of some sort?
In an event-driven CQRS architecture, the events are the result of validating commands (commands can be rejected, events can be at most ignored (but cannot be denied)). Typically you have commands coming into an application which validates them against a write-model (almost always with some sort of concurrency control which imposes an ordering), which is the authoritative source of truth emitting events for consumption by a read model.
So the question then becomes, where is your write-model?
You have a web-based portal sending events/messages to a queue. Is that portal the authoritative source of truth? If so, then it's writing events to the queue and your commands sound like they're going to be the HTTP requests and their bodies: you can structure those like you would any other web request.
On the other hand, if the processor which dequeues the message is maintaining its state and deciding what the truth is, then "application submitted" isn't an event but is a command (in which case, a more imperative phrasing is probably less confusing: "submit application").
Very often, one finds that one component's events are another component's commands.
The command pattern doesn't really have anything to do with the C in CQRS. The latter "command" is in the (to use the domain-driven-design terminology) architecture bounded context and the former "command" is in the lower-level implementation bounded context. Neither implies the other. Similarly there's a (perhaps small) distinction between "event" in the architecture bounded context (along the lines of event-driven architecture) and "event" in the implementation bounded context (along the lines of event-sourcing).
I am trying to understand observer pattern and stuck at one particular point. In my understanding, once an observer subscribes to notify them on any event change, the subscription is stored somewhere and then when event changes the subscriber is notified.
In practical scenarios I should store the values in a database or a file for persistence reasons and inform them once event occurs by getting from db and looping through the list.
Is this correct understanding? I do not see any example involving database but, every example uses list.
And again publisher/subscriber pattern is also similar except with the change that there is no exact knowledge of who the publisher and subscribers are and intermediate technologies like MQ or some sort is used to establish communication between two.
My question is : When we use DB in observer pattern wont it become publisher/subscriber ( except there is knowledge of observers and publishers here). Is it correct understanding?
In most examples for Observer pattern you would see use lists but how that list is initialized depends on your application. For example, application with huge number of subscribers would have to store these subscribers for persistence reasons just like your case. We can't expect such high number of subscribers to be in memory all the time. So the list of observers is initialized from DBs only although not all entries in one go. This is a different discussion altogether.
Secondly, simply by using DB, observer pattern and pub-sub pattern don't become similar. Even using DB, you are simply initializing your list of observers which are to be notified. There is no broker in between which would keep identities of subject and keep observer hidden from the Subject class. Here is good article that explains it nicely:
https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c
I have a project which is designed or at least should be according to the well known DDD principles.
Back - DDD + CQRS + Event Store
UI - ngrx/store
I have a lot of questions to ask about it but for now I will stick to these two:
How should the UI store be updated after a single Command/Action is executed ?
a) subscribe to response.ok
b) listen to domain events
c) trigger a generic event holding the created/updated/removed object ?
Is it a good idea to transfer the whole aggregate root dto with all its entities in each command / event or it is better to have more granular commands / events for ex.: with only a single property ?
How should the UI store be updated after a single Command/Action is executed ?
The command methods from my Aggregates return void (respecting CQS); thus, the REST endpoints that receive the command requests respond only with something like OK, command is accepted. Then, it depends on how the command is processed inside the backend server:
if the command is processed synchronously then a simple OK, command is accepted is sufficient as the UI will refresh itself and the new data will be there;
if the command is processed asynchronously then things get more complicated and some kind of command ID should be returned, so a response like OK, command is accepted and it has the ID 1234-abcd-5678-efgh; please check later at this URI for command completion status
At the same time, you could listen to the domain events. I do this using Server sent events that are send from the backend to the UI; this is useful if the UI is web based as there could be more than one browser windows open and the data will be updated in the background for pages; that's nice, client is pleased.
About including some data from the read side in the command response: this is something that depends on your specific case; I avoid it because it implies reading when writing and this means I can't separate the write from the read on a higher level; I like to be able to scale independently the write from the read part. So, a response.ok is the cleanest solution. Also, it implies that the command/write endpoint makes some query assumptions about the caller; why should a command handler/command endpoint assume what data the caller needs? But there could be exceptions, for example if you want to reduce the number of request or if you use an API gateway that do also a READ after the command is send to the backend server.
Is it a good idea to transfer the whole aggregate root dto with all its entities in each command / event or it is better to have more granular commands / events for ex.: with only a single property ?
I never send the whole Aggregate when using CQRS; you have the read-models so each Aggregate has a different representation on each read-model. So, you should create a read-model for each UI component, in this way you keep&send only the data that is displayed on the UI and not some god-like object that contains anything that anybody would need to display anywhere.
Commands basically fall into one of two categories : creation commands and the rest.
Creation commands
With creation commands, you often want to get back a handle to the thing you just created, otherwise you're left in the dark with no place to go to further manipulate it.
I believe that creation commands in CQS and CQRS can return an identifier or location of some sort : see my answer here. The identifier will probably be known by the command handler which can return it in its response. This maps well to 201 Created + Location header in REST.
You can also have the client generate the ID. In that case, see below.
All other commands
The client obviously has the address of the object. It can simply requery its location after it got an OK from the HTTP part. Optionally, you could poll the location until something indicates that the command was successful. It could be a resource version id, a status as Constantin pointed out, an Atom feed etc.
Also note that it might be simpler for the Command Handler to return the success status of the operation, it's debatable whether that really violates CQS or not (again, see answer above).
Is it a good idea to transfer the whole aggregate root dto with all
its entities in each command / event or it is better to have more
granular commands / events for ex.: with only a single property ?
Indeed it is better to have granular commands and events.
Commands and events should be immutable, expressive objects that clearly express an intent or past business event. This works best if the objects exactly contain the data that is about to change or was changed.
Anyone can detail the pros and cons to pass data from one class to another using event mechanism? When is the best time to use event to pass data?
Let's take an example. You have a system where 20 people are subscribed to a weather station for changes in weather. Do you want the weather station to keep track of all the people and services that are subscribed?
In my opinion the weather station should not know anything about the people or services that are waiting for weather changes. The weather station should just dispatch an event, and whoever is listening to it will get notified :-)
So the point is, you use events to notify observers about an action or state change that occurred in the object. Observers can be difference type of objects since you don't have to know anything about them. If someone listens to the object, then he takes care of it.
If it was one to one relation and the object waiting for something to happen is always of the same type, then you wouldn't really need an event for that case.
Events are also great to decouple systems, like seen in my example above with the weather station. The weather station can run on its own without knowing about the services or users that are listening to it.
Using events will among other things:
Decouple the event source from the event receiver
Allow multiple event receivers to subscribe to the same event
Provide a well known pattern for implementing eventing
One thing to be aware of is how delegates may create unexpected "leaks" in your code: Memory Leak in C#.
I need to implement a notification mechanism for a system that has one manager and multiple consumers/clients. A manager should poll a database and fire an event whenever there are changes in the data. Now, it'd be easy if all clients would be interested in the same data, and it would be sufficient to implement a single event and subscribe all clients to that event. However, clients should only receive the events for the data they are responsible for.
For example, there are multiple clients that add new customers. This happens through the manager in a thread-safe way. Now, these clients that created the customers need to know of any changes that happen only to those customers. The manager polls the Customers table every N seconds and gets a list of all customers that changed. Then, the manager will need to "route" (for a lack of a better word) the notifications to the interested clients.
Will this have to be implemented with some sort of a callback that each client will have to supply to the manager? This sounds like something I need, but I dont know how I can pass parameters to this callback (here, these are the customers Im interested in, dont bother me when you have updates for any other customer)
Im using C#, .NET 2.0. Thanks!
This is a good description of the Observer pattern. Typically a client registers interest with the manager for a set of data that is relevant for it, providing a means of notification (this would be your callback). A client may also unregister if it's no longer interested in previously-useful data. Then the manager's job is to propagate changes to all interested Observers (i.e. clients).
In C#, the required infrastructure is available as first-class language features - events and delegates. There is good (if simple) example code here.
In .Net 4 this convenience is taken a step further with ObservableCollection<T> available to automate the notification process.
By the way - I would avoid polling the database if possible. Is there no way you can get notified on the necessary changes in your DB? In C#/SQL Server you can use SqlDependency.