http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Rafal, Baby steps, I am doing this one step at a time.http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment7http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment7Tue, 07 Feb 2012 21:21:33 GMTYeah, not sure this is the correct method. Events should get raised from inside entities/aggregates when it makes sense, not services. In this particular case, there is already a place to raise these 2 events; cargo.DeriveDeliveryProgress. Ultimately though, when looking at this, I believe the abstractions are just wrong. We shouldn't need to call DeriveDeliveryProgress to figure out that the cargo was misdirected. It seems there are some missing concepts in here. Alas, I'm not a domain expert so I can't say for sure, but this whole bit of code seems odd.http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment6http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment6Tue, 07 Feb 2012 13:14:52 GMTNot sure where the responsibility is pushed to now. Could we have bit more of this code snippet http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment5http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment5Tue, 07 Feb 2012 12:26:54 GMTI don't understand one thing: why do you insist on having the Inspect(Cargo) method? It's unclear who should call it and when and it also shouldn't be called multiple times or event duplication will occur (and it looks innocent and safe to inspect a cargo as many times as you want). Why the event logic isn't triggered by actual cargo events occuring, for example by information about cargo being delivered/lost/mis-delivered/and so on and instead you are relying on analyzing event history during inspection?http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment4http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment4Tue, 07 Feb 2012 12:04:25 GMTThis is like the Chain of Responsability pattern....http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment3http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment3Tue, 07 Feb 2012 11:58:57 GMTOne thing what we miss from the original code is the sequence of event handling. I do not know if it is really important but your (current) solution doesn't safeguard for those situations. // Ryanhttp://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment2http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment2Tue, 07 Feb 2012 08:38:50 GMTThat's all fine and such, but you haven't limited your abstractions, you sliced the system differently. I admit it is a more favorable structure for the reasons you state, alas your code also has abstractions. in fact every time you extract a method or introduce a new class you are introducing an abstraction. Hence I would say it is not about limiting your abstractions, it is about choosing the correct ones.http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment1http://ayende.com/153953/limit-your-abstractions-application-events-proposed-solution-1#comment1Tue, 07 Feb 2012 08:32:53 GMT