Should domain events be dispatched according to event classes, or classes and a topic?
For example, I have the following event:
class UserRegisteredEvent implements INonTransactionalEvent{
public Timestamp: TTimestamp;
}
And an event manager,
class EventManager {
/** Omitted **/
}
Udi Dahan proposes that events are first class objects, and I like that. There is a UserRegisteredEvent object, an OrderComplete object. My question is, does the type itself get bound to the event handlers? For example, should I just pass the event object to the publish method?
EventManager.Publish(new UserRegisteredEvent(1));
This means each handler is bound to a single class type, which seems limiting. While YAGNI may be true, is the following not more powerful:
EventManager.Publish(new UserRegisteredEvent(1), Events.UserRegistered)
Whereby the event topic is what the handlers bind to. This way, handlers can benefit from inheritance. If type safety or usage of a ubiquitous language was an issue, one could do:
EventManager.UserRegisteredEvent(1)
Which is simply a short method to the longer publish version. This annoys me a little, as it means the class must be altered for every new event, which seems unnecessary (and indeed, not necessary if using the above method).
While I've only seen events get published as classes with no topic, is this limiting, or has anyone run into issues with this?
Domain events don't really require a specific implementation. After all they are just semantic DTOs. I don't understand what you're trying to accomplish, but unless you're building a service bus you just send the event object to be handled by whatever handlers are configured.
The Event doesn't know about the handlers, the handlers don't know about each other, the bus knows how to send the event to the handlers. And you want a handler to explicitly handle only 1 event, SRP . You can combine implementations of related handlers into one class, but that's an implementation detail.
If you really feel like introducing topics, I'd do it through interface inheritance. For instance:
interface IUserEvent : INonTransactionalEvent { ... }
class UserRegisteredEvent implements IUserEvent {
public Timestamp: TTimestamp;
}
The impact in your code and language would be negligible, you can keep using a generic Publish method accepting INonTransactionalEvent and you can also easily refactor your topics.
Related
I'm aware it's a complex question that cannot have a definite answer without posting a few hundreds of lines of code, which is why I'm looking for help through general ideas and pointers.
I have a Room #Query returning a RxJava3 Flowable<List<...>> which I subscribe to on RxJava thread Schedulers.io(), and observe from an activity-scoped ViewModel on RxJava thread AndroidSchedulers.mainThread(). The data is then stored in my ViewModel as LiveData, which plays better than RxJava when it comes to handle Android components' lifecycle.
The idea is to have a clean and immediate data update pattern, not to have to handle disposal and re-subscription separately on each activity or fragment lifecycle event such as onPaused and onResumed, and being updated in the background even when my activity is hidden in order to avoid that awful refresh lag when returning to my activity. I was pretty amazed at that design pattern. I still am, but I'm beginning to have doubts.
When starting another activity with the same design pattern, I do change a value and immediately get an updated List<...> from the other ViewModel. Different Activity, different ViewModel, same design, same database table. When returning to the first Activity, I find that the new data does never get updated: Room did not emit any update even though the data set has changed. I have to dispose and subscribe again in order to see the new data.
So my question is: any pointer on where the source of my problem might be?! Is there something rotten in the core of this design pattern? Something I misunderstood about all those things are supposed to work together? Is it just a mistake of mine due to some threading issue? Or should I fill a bug report for Room?
I tried to observe another non-Room RxJava3 observable from the ViewModel of my first Activity, and it does get updates when its data set is updated.
By the way, I also use Hilt in order to inject eveything as #Singleton.
Thank you for your time :-)
After a week of headaches, I have finally stumbled upon a solution, which happens to be clean and elegant.
The issue was RxJava, which, I just learnt, is not supposed to seamlessly handle multiple subscriptions to the same Observable. The solution is supposedly to make use of the publish(), connect(), refcount() operators, or better use the shortcut share(). I tried every way I could think of, without success (it actually made it worse). I also tried to subscribe() to the Room Flowable from my repository and proxy it through a BehaviorSubject.
There was this weird org.reactivestreams.Publisher in Room's documentation, whose added value I wouldn't know, and whose origin wasn't even my familiar io.reactivex.rxjava3. It turns out it that was the solution. Edit: It turns out Publisher is an interface that Flowable happens to implement.
build.gradle
implementation 'android.arch.lifecycle:reactivestreams:+'
Dao.java
#Query("...")
Flowable<List<...>> getFlowable();
ViewModel.java
public liveData;
#Inject
public ViewModel(#NonNull RoomDatabase roomDatabase) {
liveData = LiveDataReactiveStreams.fromPublisher(roomDatabase.dao().getFlowable());
}
It seems too easy to be true, but as far as I can see it seems to work perfectly better this way.
Edit:
It turns out the root of this issue was a slight little bit more vicious than I thought. I assumed #InstallIn(SingletonComponent.class) in my dependency injection #Module was enough, but apparently a #Singleton annotation on each #Provides method is also required.
#Module
#InstallIn(SingletonComponent.class)
public abstract class DependencyInjection
{
#Provides
#NonNull
#Singleton // do not omit this
public static DataDao provideDataDao(#NonNull RoomDatabase roomDatabase) {
return roomDatabase.dataDao();
}
#Provides
#NonNull
#Singleton // do not omit this
public static RoomDatabase provideRoomDatabase(#ApplicationContext Context applicationContext) {
return
BuildConfig.DEBUG ?
Room.databaseBuilder(applicationContext, RoomDatabase.class, "playground.db").fallbackToDestructiveMigration().build() :
Room.databaseBuilder(applicationContext, RoomDatabase.class, "playground.db").build() ;
}
}
For my application I need to fetch some data asynchronously and do some initialization for each page. Unfortunately, a constructor does not allow me to make asynchronous calls. I followed this article and put all of my code into the OnAppearing method. However, since then I ran into multiple issues since each platform handles the event a little bit differently. For example, I have pages where you can take pictures, on iOS the OnAppearing is called again every time after the camera is closed while Android doesn't. It doesn't seem like a reliable method for my needs, which is also described here:
Calls to the OnDisappearing and OnAppearing overrides cannot be treated as guaranteed indications of page navigation. For example, on iOS, the OnDisappearing override is called on the active page when the application terminates.
I am searching for a method/way where I can perform my own initialization. The constructor would be perfect for that but I cannot perform anything asynchronously in there. Please do not provide me with any work arounds, I am searching for a solution that is the "recommended" way or maybe someone with a lot of experience can tell me what they are doing. (I also don't want to .Wait() or .Result as it will lock my app)
You can use Stephen Cleary's excellent NotifyTaskCompletion class.
You can read more how it works and what to do/don't in these cases in Microsoft's excellent Async Programming : Patterns for Asynchronous MVVM Applications: Data Binding. The highlights of this topics are:
Let’s walk through the core method
NotifyTaskCompletion.WatchTaskAsync. This method takes a task
representing the asynchronous operation, and (asynchronously) waits
for it to complete. Note that the await does not use
ConfigureAwait(false); I want to return to the UI context before
raising the PropertyChanged notifications. This method violates a
common coding guideline here: It has an empty general catch clause. In
this case, though, that’s exactly what I want. I don’t want to
propagate exceptions directly back to the main UI loop; I want to
capture any exceptions and set properties so that the error handling
is done via data binding. When the task completes, the type raises
PropertyChanged notifications for all the appropriate properties.
A sample usage of it:
public class MainViewModel
{
public MainViewModel()
{
UrlByteCount = new NotifyTaskCompletion<int>(
MyStaticService.CountBytesInUrlAsync("http://www.example.com"));
}
public NotifyTaskCompletion<int> UrlByteCount { get; private set; }
}
Here, the demo is about binding the returned asynchronous value to some bindable property, but of course you can you is without any return value (for simple data loading).
This may be too simple to say, but you CAN run asynchronous tasks in the constructor. Just wrap it in an anonymous Task.
public MyConstructor() {
Task.Run(async () => {
<Your code>
}
}
Be careful when doing this though as you can get into resource conflict issues if you accidentally open the page twice.
Another thing I like to do is use an _isInit flag, which indicates a first time use, and then never again.
I will explain with an example. My GWT project has a Company module, which lets a user add, edit, delete, select and list companies.
Of these, the add, edit and delete operations lands back the user on the CompanyList page.
Thus, having three different events - CompanyAddedEvent, CompanyUpdatedEvent and CompanyDeletedEvent, and their respective event handlers - seems overkill to me, as there is absolutely not difference in their function.
Is it OK to let a single event manage the three operations?
One alternative I think is to use some event like CompanyListInvokedEvent. However, somewhere I think its not appropriate, is the event actually is not the list being invoked, but a company being added/updated/deleted.
If it had been only a single module, I would have get the task done with three separate events. But other 10 such modules are facing this dilemma. It means 10x3 = 30 event classes along with their 30 respective handlers. The number is large enough for me to reconsider.
What would be a good solution to this?
UPDATE -
#ColinAlworth's answer made me realize that I could easily use Generics instead of my stupid solution. The following code represents an event EntityUpdatedEvent, which would be raised whenever an entity is updated.
Event handler class -
public class EntityUpdatedEvent<T> extends GwtEvent<EntityUpdatedEventHandler<T>>{
private Type<EntityUpdatedEventHandler<T>> type;
private final String statusMessage;
public EntityUpdatedEvent(Type<EntityUpdatedEventHandler<T>> type, String statusMessage) {
this.statusMessage = statusMessage;
this.type = type;
}
public String getStatusMessage() {
return this.statusMessage;
}
#Override
public com.google.gwt.event.shared.GwtEvent.Type<EntityUpdatedEventHandler<T>> getAssociatedType() {
return this.type;
}
#Override
protected void dispatch(EntityUpdatedEventHandler<T> handler) {
handler.onEventRaised(this);
}
}
Event handler interface -
public interface EntityUpdatedEventHandler<T> extends EventHandler {
void onEventRaised(EntityUpdatedEvent<T> event);
}
Adding the handler to event bus -
eventBus.addHandler(CompanyEventHandlerTypes.CompanyUpdated, new EntityUpdatedEventHandler<Company>() {
#Override
public void onEventRaised(EntityUpdatedEvent<Company> event) {
History.newItem(CompanyToken.CompanyList.name());
Presenter presenter = new CompanyListPresenter(serviceBundle, eventBus, new CompanyListView(), event.getStatusMessage());
presenter.go(container);
}
});
Likewise, I have two other Added and Deleted generic events, thus eliminating entire redundancy from my event-related codebase.
Are there any suggestions on this solution?
P.S. > This discussion provides more insight on this problem.
To answer this question, let me first pose another way of thinking about this same kind of problem - instead of events, we'll just use methods.
In my tiered application, two modules communicate via an interface (notice that these methods are all void, so they are rather like events - the caller doesn't expect an answer back):
package com.acme.project;
public interface CompanyServiceInteface {
public void addCompany(CompanyDto company) throws AcmeBusinessLogicException;
public void updateCompany(CompanyDto company) throws AcmeBusinessLogicException;
public void deleteCompany(CompanyDto company) throws AcmeBusinessLogicException;
}
This seems like overkill to me - why not just reduce the size of this API to one method, and add an enum argument to simplify this. This way, when I build an alternative implementation or need to mock this in my unit tests, I just have one method to build instead of three. This gets to be clearly overkill when I make the rest of my application - why not just ObjectServiceInterface.modify(Object someDto, OperationEnum invocation); to work for all 10 modules?
One answer is that you might want want to drastically modify the implementation of one but not the others - now that you've reduced this to just one method, all of this belongs inside that switch case. Another is that once simplified in this way, the inclination often to further simplify - perhaps to combine create and update into just one method. Once this is done, all callsites must make sure to fulfill all possible details of that method's contract instead of just the one specific one.
If the receivers of those events are simple and will remain so, there may be no good reason to not just have a single ModelModifiedEvent that clearly is generic enough for all possible use cases - perhaps just wrapping the ID to request that all client modules refresh their view of that object. If a future use case arises where only one kind of event is important, now the event must change, as must all sites that cause the event to be created so that they properly populate this new field.
Java shops typically don't use Java because it is the prettiest language, or because it is the easiest language to write or find developers for, but because it is relatively easy to maintain and refactor. When designing an API, it is important to consider future needs, but also to think about what it will take to modify the current API - your IDE almost certainly has a shortcut key to find all invocations of a particular method or constructor, allowing you to easily find all places where that is used and update them. So consider what other use cases you expect, and how easily the rest of the codebase can be udpated.
Finally, don't forget about generics - for my example above, I would probably make a DtoServiceInterface to simplify matters, so that I just declare the one interface with three methods, and implement it and refer to it as needed. In the same way, you can make one set of three GwtEvent types (with *Handler interfaces and possibly Has*Handlers as well), but keep them generic for all possible types. Consider com.google.gwt.event.logical.shared.SelectionEvent<T> as an example here - in your case you would probably want to make the model object type a parameter so that handlers can check which type of event they are dealing with (remember that generics are erased in Java), or source from one EventBus for each model type.
When dealing with events, people are usually taking examples of very simple values object composed only of primitives.
But what about an event where i would need more information. Is is allowed to create specific structure to handle these cases ?
namespace Events {
public class BlueTrainCleaned
{
Datetime start
Datetime end
Carriage[] Carriages
}
public class Carriage
{
string Descrizione
int Quantity
}
}
The Carriage class is part of the event namespace and has not any complex logic or anything.
but if I had another event :
public class RedTrainCleaned
{
Datetime start
Datetime end
Carriage[] Carriages
}
Carriage will be part of the interface of the second event also. If have let's say 40 or 50 event with the same "event value object", that means that my project will be heavily coupled on this object. It does not look so good to me, but what could I do to avoid this? Is it a warning that something in the analysis of my domain is not well done?
thanks for your help,
I guess it depends on how standard Carriage is in your domain. If it changes for one event, should it change for the other ones, too?
I guess I think of the example of Address. It's pretty standard within a domain, and I think it makes sense to include that in my event object if I am raising an event that contains address information. This way, if it becomes known that we need to have a ZIP+4 extension to my zip code, I can add a new field to my Address class and have that property available for future events. I can make the change in a single place and have it available for future events.
If Carriage could mean something different across different events, then maybe it's not something you should include - and instead, flatten it out in your event. But if Carriage really is an ubiquitous definition within your domain, then I think it's fine to include it in your event classes.
As much as it may be frustrating to hear, I think it really "depends".
I hope this helps. Good luck!!
A separate class library project can be created to contain message classes (DTO's). This project ideally should have no dependencies on other projects of the solution, and it should contain nothing but serializable POCO's.
There will be minimal dependency in this case as you only have to share the DTO library.
I'm trying to implement Domain Driven Design in my Symfony2 project and experience some problems.
After reading some articles on Domain Models I found, that
I should put all the business logic into my domain models(entities).
Application level stuff, that needs to be done and doesn't belong to domain logic is fired with Domain Events(sending emails, putting some messages to the queue, etc.)
Luckily, Symfony provides Events, but here is a problem - I can't raise event from my entity.
Symfony documentation suggects to use DI to inject the dispatcher into the class, that raises Event
http://symfony.com/doc/current/book/internals.html#passing-along-the-event-dispatcher-object
But Symfony Entities are newable, not injectable.
Right now I can see two ways:
1) Provide Event Dispather to Entity like this
class FooEntity
{
protected $dispatcher = null;
public function setEventDispatcher(EventDispatcher $dispatcher)
{
$this->dispatcher = $dispatcher;
}
}
2) Raise Events from the service(not from the Entity).
None of this options look pretty, because it seems to me that they break Domain Model ideology.
Can you point me in the right direction, please.
The idea of this here is to give paths to attain the DDD paradygm.
I do not want to shadow over #magnusnordlander answer, I will apply what he says.
Here is some of observations on the matter:
I think that the Entity itself should not have everything. It is sure not what the DDD people would say anyway. The [Doctrine2] Entity should only take care of the relationships (an entity with different variation too <= This is actually a thing that I was stuck for a while) and the aggregate root.
The Doctrine entity should only know about how to work with itself.
But, to Get Data or work with it, there is other stuff that you can use:
Repository
Is the thing that provides helpers to get your more sophisticated finders than what a quick findBy(array('id'=>$idvalue)) would do (and that the Entity/Assocation/Annotation cannot cover) and is indeed a great thing to have handy.
I personally tried to build all queries, and realized the EntityManager is already very good, out of the box. In most case, to my opinion: If you can /not/ use query or query builder, the better.
Business logic in all that...
Last thing on note, what you would be searching for must be to basically thin the Controller.
FooManager (for example) is where (if I am not mistaken) the business logic go.
I found a goldmine of information on that matter on this blog that covers:
Controllers and application logic revisited
Putting controllers in a diet, and mix it with some custom Event with
Leveraging the Symfony2 Event dispatcher
If you have any ideas, to augument, I set this answer as a Community Wiki
By Symfony entities, do you mean Doctrine 2 entities? If so, you can set services on both new objects and old objects that are loaded from the database in the following manner:
Prototype scoped service
Services in the prototype scope are always recreated when you get them. Instead of doing new FooEntity you would do $container->get('foo_entity').
In the YAML syntax you would define the service as follows:
foo_entity:
class: FooEntity
calls:
- [setEventDispatcher, [#event_dispatcher]]
scope: prototype
This will take care of new entities. For existing entities you need a...
Post load event listener
Create an event listener, in the manner described here:
http://symfony.com/doc/current/cookbook/doctrine/event_listeners_subscribers.html
Have the listener listen for the postLoad-event. Inject the event dispatcher into the listener service, and use the listener service to set the event dispatcher on the entity.
Bear in mind that the listener service will fire after loading any entity, not just the FooEntity, so you'll need to do a type check.