I'm working for a while with silverlight and MVVM (in its simplest form, it's to say hand-made), but I barely understand what is an event aggregator (and how to make an implementation of this).
What is hidding behind this name?
Can someone explain this quickly (or post a link?).
An event aggregator is generally a broker object that you can take a reference to and specify what type of events you want to receive, without having to take a reference or even be aware of the objects generating the events.
Prism's EventAggregator is the most common one. See: http://msdn.microsoft.com/en-us/library/ff649187.aspx
It describes itself as:
The EventAggregator service is
primarily a container for events that
allow decoupling of publishers and
subscribers so they can evolve
independently. This decoupling is
useful in modularized applications
because new modules can be added that
respond to events defined by the shell
or, more likely, other modules.
Related
I am thinking what is the best way to structure your micro-services, in the past the team I was working with used Axon Framework and PostgreSQL and each microservice had its own event store in the PostgreSQL database, then we built communication between using REST.
I am thinking that it would be smarter to have all microservices talk to the same event store as we would be able to share events faster instead of rewriting the communication lines using REST.
The questions that follows from the backstory is:
What is the best practice for having an event store
Would each service have its own? Would they share the same eventstore?
Where would I find information to inspire and gather more answers? As searching the internet for best practices and how to structure the Event Store seems like searching for a needle in a haystack.
Bear in mind, the question stated is in no way aimed at Axon Framework, but more the general idea on building scalable and good code. As the applications would work with each own event store for write model and read models.
Thank you for reading and I wish you all the best
-- Me
I'd add a slightly different notion to Tore's response, although the mainline is identical to what I'm sharing here. So, I don't aim to overrule Tore, just hoping to provide additional insight.
If the (micro)services belong to the same Bounded Context, then they're allowed to "learn about each other's language."
This language thus includes the events these applications publish and store.
Whenever there's communication required between different Bounded Contexts, you'd separate the stores, as one context shouldn't be bothered by the specifics of another context.
Hence it is beneficial to deduce what services belong to which Bounded Context since that would dictate the required separation.
Axon aims to support this by allowing multiple contexts with the Axon Server, as you can read here.
It simply allows the registration of applications to specific contexts, within which it will completely separate all message streams (so commands, events, and queries) and the Event Store.
You can also set this up from scratch yourself, of course. Tore's recommendation of Kafka is what's used quite broadly for Event Streaming needs between applications. Honestly, any broadcast type of infrastructure suits event distribution, as that's how events are typically propagated.
You want to have one EventStore per service, just as you would want to have one relation database per service for a non EventSourced system.
Sharing a database/eventstore between services creates coupling and we have all learned the hard way that this is an anti-pattern today.
If you want to use a event log to share events across services, then Kafka is a popular choice.
Important to remember that you only do event-sourcing within a service bounded context.
I want to communicate my services using events. I gonna publish (internally) all my domain events and allow any other service to subscribe to them. But such approach couples those services togheter. I am not longer allowed to change my events. This is even worse than local coupling because I dont event know my consumers any more. This limits the ability of developing/refactoring to unacceptable dedree. I am thinging about versioning my events which solves most of the issues. But how to subscribe to versioned events? Introducing common interface that groups all event`s versions and then downcast event within listener to accepted one does not sound like a vital solution. I also take into account publishing all supported versions of the event to the bus. By definition each subsriber will handle just one version. I dont want my domain to by involved in this matters so I need to build kind of infrastructure listener that will be translate catched events to other versions. I cant find anything about that topic in the Internet which automatically makes me think if I am not thoroughly wrong :)
UPDATE: After a lot of thought, I no longer want to publish my domain events. I think it is no desirable to expose internal service mechanics to the outer world. It also could violate some domain data access restriction. I think, the way to go is to map my domain events to some more corase integrational events. But I still need way to wersion them probably :)
UPDATE2: After some consultations an idea came up. Assuming we stick to the concept of integration events. Such events may be considered just as type and event id. So outer listener just focus on event type. If event occur then listener will be provided with event id. This enable listener to fetch real event from the stream/bus/wtf in given version. $eventsStore->get($eventGuid, $eventType, 'v27') for example (PHP syntax)
I gonna publish (internally) all my domain events and allow any other service to subscribe to them.
This is a common pattern in Even-Driven Architecture. I assume that you publish the events on an Event Broker, e.g. Apache Kafka and that Consumers subscribe to topics on the Event Broker.
I am not longer allowed to change my events. This is even worse than local coupling because I don't event know my consumers any more. This limits the ability of developing/refactoring to unacceptable degree. I am thinking about versioning my events which solves most of the issues.
Nah, published contracts should be versioned and no backward incompatible changes can be added to them. If you need a change that is not backward compatible, you have to introduce a new version of the published contract - and keep the old one as long as there is consumers. This is no different from REST-based interfaces - you have to fulfill your contracts.
With REST you may do this by using both /v1/orders and /v2/orders at the same time. With an Event-Driven Architecture you use two topics e.g. orders-v1 and orders-v2 - and these two contain data following a schema, e.g. Avro.
With an Event-Driven Architecture, where the services are decoupled (with a broker in between), you can actually phase out the old producer, if you add a smaller transformer, e.g. that consume orders-v2 and transform the events to the old format and publishes them on orders-v1 - so both v1 and v2 is still published.
Building Event-Driven Microservices is a good book about this.
I am trying to develop a multi-agent application in F#. Here's what I'm trying to do:
Create few agents (say, 100).
Have these agents asynchronously communicate with each other, using events.
HOWEVER, a requirement is that each of these agents should have no knowledge of each other.
The essence of the above point is that, for an agent (say A1, who's the publisher in this case) to send an event to another agent (say A2, who's a subscriber), the agent A2 needs to instantiate A1 to receive notifications from it. Both the Events framework in F# and the Reactive Extensions (Rx) follow this instantiation methodology.
What I'm looking for is a F# based event-broker-framework/middleware that allows an agent to subscribe to an event without instantiating the agent which publishes that event. i.e. the agents do not have knowledge of other agents the system. They just know the list of events that exist, and subscribe to (one or more) events from that list. On receiving the subscribed event(s), the agent invokes one of its methods.
One solution I can think of for this is the Event Aggregator pattern (e.g. in Prism). But haven't seen any F# implementation of this pattern.
Any reference/pointers would be appreciated. Thanks in advance.
You may be interested in reactive programming with the Reactive Extensions framework. It lets you create and manipulate event streams.
A basic introductory scenario would be to create a Subject to which your agents can subscribe or send events, thus acting as either producer or consumer.
I'm not sure if there are any concrete F# implementation of different eventing patterns, but the framework itself is incredibly powerful and definitely worth investigating in my opinion.
I have designed and developed my application in MVP Pattern. I have not used any software factory to achieve this. Now i want to shift to SCSF pattern and CAB structure.
I need to know if it can be done in any easier way as CAB structure implements MVP only.
I would agree with Wali. you have got your views ready . Assuming they are in perfect MVP. now you need to classify them into Modules.
We created child workitems, so that when a use case is started it was a new instance of child workitem added to the workitems collection of the module. So when the use case is completed we simply terminated the child workitem. If any exception occurs then the childworkitem is the one going to be affected now the Module's work item.
SCSF has feature where you can compose multiple views on the screen. So you need to look out if you can use ZoneWorkspace to avoid duplicate UI and logic.
Decide how the modules are going to communicate, say events or Commands.
How data is going to be passed between views and modules. Now you have the Shell, you need to decide what all regions you are going to have on the shell. What comes by default on the shell. How the modules listen to Shell. What events Shell listen from modules to customize itself.
SCSF has dependency injection. So decide what are the UI Services you are going to have. Inject them in to Presenter accordingly.
In CAB and SCSF, there is code-ready MVP classes (and interfaces). So if you have implemented it cleanly, then you can just copy your methods once you get a hang of the classes.
Will try to brief it :-
1) IView -- Its a reference of View, which exposes only those set properties/Methods which can be accessed by Presenter (or any other class)
2) View -- It has a reference of Presenter and can access all the public/protected methods of presenter. By design it cannot access any service, as you would require WorkItem (container of Services, State, Command, Events Etc). For all practical purpose View is only there to manage the UI controls, Binding, State of object Etc.
3) Presenter -- It has a reference to WorkItem (through which you can access all the services). Presenter's responsibility it to manipulate data with the help of Services.
4) WorkItemController -- WorkItemController can take UseCase related functionality as in wiring/unwiring of ui controls, positioning of view etc.
Its more than just MVP in SCSF/CAB as its overall design of a UI Application. Which has the following :-
Modular Structure
On-Demand architecture.
Service Pattern
Commands
Event Handlers
Etc.
So firstly you have to check codeplex docs to see if your project would be easily upgraded in that platform/architecture. I would recommend CAB/SCSF if you have just begun and thinking of making the project scalable and enterprise level.
Pattern of pub-sub events is that the
publisher should not know or care if
there are any subscribers out there,
nor should it care what the
subscribers do if they are there (from
Brian Noyes'
blog)
What are the best practices to using EventAggregator in Prism? Currently I have few modules which are loosely coupled and work independently. These modules use EventAggregator to communicate to other modules. As the application grows I'm confused on how to document my code. There could be many modules publishing Events and many others subscribing to it as Brian puts neither of them knows what other does exactly. When creating a new module how do I make sure they are subscribed to some XYZ event without breaking the loosely coupled structure?
How do I represent a module using EventAggregator visually (some kind of diagrams)?
You have a lot of questions in your post that can be answered "it depends on your application," but I'll try to answer some of them.
One thing that I see most often with EventAggregator is abuse. Many people use EventAggregator in a way that makes both the publisher and subscriber dependent on each other. This brings me to my first bit of advise:
Never assume there are any subscibers to an event.
EventAggregator is useful for publishing events other views might be interested in. For example, in our application we allow a user to change someone's name. This name might be displayed on other views already open in the application (we have a tabbed UI). Our use case was we wanted to have those UIs update when the name was changed, so we published a "UserDataChanged" event so that open views could subscribe and refresh their data appropriately, but if no views that were open were interested in this data, no subscribers were notified.
Favor .NET Events over EventAggregator events where appropriate
Another mistake I see frequently is a business process that is implemented using EventAggregator where data is sent to a central party and then that party replies, all using EventAggregator. This is leads to some side-effects you'd likely want to avoid.
A variation on that I see a lot is communication from a parent view to a sub-view, or vice-versa. Something like "TreeItemChecked" or "ListViewItemSelected". This is a situation where traditional .NET Events would be used, but an author decided that if they have a hammer (EventAggregator), everything (Events) looks like a nail.
You asked about modeling the EventAggregator and I would say this: the EventAggregator is only special in that it allows for decoupling and doesn't create strong references to events (avoiding memory leaks, etc). Other than that, it's really just a very slight variation of the Observer Pattern. However you are modeling Observers is how you would model the EventAggregator in whatever type of diagram you are trying to create.
As to your question about making sure some module or another is subscribed to an event: you don't. If you need to ensure there are subscribers, you should not use the EventAggregator. In these cases I would recommend a service running in your application that modules can grab from your container and use or other similar thing.
The thing to keep in mind about your modules is that you should be able to completely remove one and the rest of your application functions normally. If this is not the case, you either have a module dependency (best to be avoided, but understandable), or dependent modules should be combined into one.