Type discriminator or separate classes for domain events?

[Jeremy Lew]

I have a legacy system that I am trying to infuse with many of the architectural patterns that concern list members here.  It is not DDD (or at least not disciplined DDD), but I thought people might have some insight, and please excuse any misues of terminology like "entity":

 

The "domain model" consists of activities of different types. There is the concept of a basic activity which has common properties like a name and the ability to be scheduled.  Subtypes have their own specific information and behaviors.  I want to publish various events about what has happened to these things.  Does anyone have guidance on whether it is better to model event messages (ActivityScheduled) as a single message type with an ActivityType discriminator property, or to have one message-type per activity-type (ActivityTypeAScheduled, ActivityTypeBScheduled)?

 

Thanks,

Jeremy

[Elliot Ritchie]

Do the activity subtypes really have their own behaviours? i.e. Do
they expose more than the same 'Schedule()' methods that the basic
activity has? If the answer's no then you don't really need to
differentiate 'why' something changed within your system when
scheduling activities (You probably don't need all the different sub-
types either) and can raise a single ActivityScheduled event type with
an ActivityType property.

If the answer's yes then you'll probably have different sub-types
because they expose different behaviour from one another, in which
case you should raise separate events.

Hope this helps.

[Tom Janssens]

Why not both ? The cost is close to zero anyway ?

[Peter Ritchie]

We've done this.

 

There's caveats and benefits to both.  sub-type events are the most work.  It's certainly the most object-oriented; but you end up either dropping down to a type (activity type, or worst-case instance type) or write reasonably complex double-dispatch implementations.  If your team is well-versed in patterns like double-dispatch; subtypes might be the way to go.  If not, you'll have the potental of running into many obscure problems...  We have a mix of both, both subtype and "activity-type"; the sub-type implementation gave us the most grief with the junior members.

 

Cheers -- Peter

--
"Refactoring with Microsoft Visual Studio 2010": http://lynk.at/c13trs
http://PeterRitchie.com/blog/
http://twitter.com/PeterRitchie
http://facebook.com/Peter.Ritchie/
http://www.linkedin.com/in/PeterARitchie
Skype:Peter.a.Ritchie

[Jeremy Lew]

Yes, the activity subtypes have different behaviors (at a certain point. They have a lot of common behaviors too.)  With respect to scheduling , they would be the same.  Perhaps that's the answer (maybe what Tom meant,) use either/or depending on the situation.

[Jeremy Lew]

For some of these things, I can maybe whip up a T4 template or two, so that it's less of a manual coding task.  But point well taken about complexity.

Thanks,
Jeremy

[Peter Ritchie]

An event with behaviour?  Could you provide an example of this?

On Mon, May 23, 2011 at 10:48 AM, Jeremy Lew <jerem...@gmail.com> wrote:

Yes, the activity subtypes have different behaviors (at a certain point. They have a lot of common behaviors too.)  With respect to scheduling , they would be the same.  Perhaps that's the answer (maybe what Tom meant,) use either/or depending on the situation.

[Jeremy Lew]

No, the entities have behavior.  Events are DTOs.

[Michael Brown]

I’m going to be a weasel and say “it depends”. Depending on how your events are pushed to the recipients. For instance, in my framework, I allow subscribers to filter what events they receive using an expression when they register for it. So I can say

bus.RegisterFor<ActivityScheduled>(ev=>ev.EventType==EventType.Wedding);

In general though, I try to avoid enums and prefer to use polymorphism to dictate code paths. And thanks to co/contravariance in C# 3 I can configure my bus to send the more generic ActivityScheduled event to those who want them as well as the more specific WeddingScheduled event for those who care.

Here's the kicker. If your event types are dynamic (meaning new event types can be added at runtime), you obviously CAN'T use inheritance ... well you could but you'd be getting into the world of dynamic work flows, transforms, and business rules and at that point you might as well be using a full-fledged BR/workflow engine.

[Peter Ritchie]

You could also do something like this:

 

var weddingEvents = eventCollection.OfType<WeddingEvent>();

//... do something with weddingEvents

 

...asuming "WeddingEvent" is a derived type...

 

i.e. using a type field is no less filterable than using a subtype.

 

I would recommend using a type field when you want to support "types" outside of an OO context (like over the wire or in flat files) when you no longer have an "instance".

 

Cheers -- Peter

[Tom Janssens]

I meant:
Publish both a CustomerConsumedFoodEvent and a CustomerConsumedCarrotCakeWithWhipCreamEvent; if there is a reason for the distinction, make this explicit by using 2 different events; the naming can show that there is a relation between the 2, but I would advise strongly against making your events dependent on eachother.