One of the best feature that C# offers to modelers is the event pattern.
In general, this pattern is expressed as formal naming conventions for
delegates, events, and related methods involved in the event notification
process. Thanks to this slight variation on the classical observer pattern,
.NET developers can easily decouple the subject and the observer.
This is not the medication for all ills, however: everybody knows the memory leaks that forgotten delegates can cause.
Epic provides a set of tool to take full advantage of the smart pattern proposed from Microsoft without the connected risks.
First of all, we noted that only the entities can be subject to observation, as they own an identity.
The underlying rationale is that whenever an entity recieves a command, it should inform the world about what happened. This should not be a technicality, based on a naming convention connected to the invoked command or related to the changed data.
The name of the event should be a verb in past tense that expresses what
happened. The event sender will tell to the observer about who is the
protagonist of the news.
The custom EventArgs should describe the news itself, providing informations
useful to domain experts.
This simple set or rules produces a really powerfull tool, solving a number of apparently unrelated problems such as GUI sincronization, persistence, logging, high availability and so on.
For example, a presenter built with Epic.Poem can take advantage of the model’s events to update the view, a repository can observe the entities to update the db or to log something. No more need for presentation models, data models and so on, with Epic there’s no other model before the domain model.
Back in the 2008, Udi Dahan introduced the concept of "Domain Events" that rapidly became popular in the domain-driven comunity as Evans talked about them in 2010.
Almost concurrently, we were developing our brand-new application, based on the (at time evolving) patterns described here. I remember quite well the discussions we had about the Dahan’s proposals. I would like to say that we kept the previous approach due to design considerations, but guess what? The decision was already taken due to the advanced status of the project.
That being said, I prefer our previous approach. With my architect hat on, I saw a major issue in Dahan’s method: implicitness.
Only the code knows which events that an command can fire. You should read the code of each entity to see which events you could subscribe. You could add relevant events without changing the clients. [4]
Even if we had had time to change the existing code base, I would had dislike the choice. Indeed with Epic and the Observable Entities pattern you could get all the advantages of the dispatching tecnique described, in a much more explicit and natural way (since the .NET events can be exposed in the contracts).
What if a relevant event do not belong to any known entity?
Although very uncommon, such circumstance exists.
The "Domain Events" pattern would handle the headless events as all others.
In the context of Epic, instead, you have to model them as events connected to the one that percieve them: the user (playing a role). Indeed, each user has an identity, and when he play a bounded role, he can percieve interesting events from the outside world. We just transferred such simple observation into the code (explicitly, in the contracts).
[4] If you maintained a complex corporate software for more than one
year and you aren’t paid by the hour, you know how such implicitness can
become a nightmare during deployments.
There’s no denying that there is a profitable software business in
extraordinary repairs (even if due to bugs left behind).
However Epic is designed for high-quality software: if you need such kind of
long term revenues, you should avoid the complexity of its approach.