Jan, have a look at Udi Dahan's presentation on CQRS (http:// skillsmatter.com/podcast/open-source-dot-net/udi-dahan-command-query- responsibility-segregation). It sounds like you are sort of moving in that direction. He may be able to shed some light on the topic for you. I found the presentation incredibly eye opening for how I can better architect the user experience.
What I took away from the material is: 1. data presented to the user is stale. 2. a single source of truth is not required for all systems. 3. CQRS isn't that complex. it's complicated with lots of moving parts, but parts are small and simple. I say all this in light of your comments about... "But this would somewhat transgress the borders between domain and services, wouldn't it?" "...the saga would have to become its component and subsequently have to move into the domain..." "A message becoming part of the entity? After all, I have to query for that state quite often..." On Mar 17, 10:07 am, Jan Limpens <[email protected]> wrote: > On Mon, Mar 15, 2010 at 11:33 PM, Jan Limpens <[email protected]> wrote: > >> 1/ bus.DelaySend > > > how could I cancel this, in case the payment arrives? > > I could of course, upon state change delaysend a > CheckIfIsStillInStateMessage, that would either be answered with a > AbendondedWarningMessage or nothing. Would this be the way to go? (A > bit non-obvious in my eyes) > > >> 3/ A saga is just a way to encapsulate a state machine, it is pretty > >> common to have the current state flag in the saga state. > > Ah, I see so the saga would actually be _the_ place where the state is saved. > But this would somewhat transgress the borders between domain and > services, wouldn't it? > If my order object is an entity (persited via nhib), the saga would > have to become its component and subsequently have to move into the > domain (not doing domain like things, being persistence conscious). > I had imagined that the Order exposes a state setter, that the service > would be able to change from the outside. > On impl level I have no idea how this could work. A message becoming > part of the entity? > After all, I have to query for that state quite often... > > > > >> On Tue, Mar 16, 2010 at 1:17 AM, Jan Limpens <[email protected]> > >> wrote: > > >>> hello, > > >>> a few more question on how to implement things in a nice way :) > > >>> I have an OrderSaga and I want it to send a message if n days went by and > >>> the customer has not yet paid for the order. I suppose it is no good idea > >>> to > >>> Thread.Sleep for n days :) > >>> How does one implement such a thing? > >>> Is the saga kept alive for the whole period of its non-conclusion or is > >>> it brought to live every now and then and checked, if there is something > >>> that needs to be done? > > >>> Should I reference the persisted Order in the Saga (via it's id)? > > >>> If the Order has an enum State of possible states, should my OrderStates > >>> class (the one I pass to the Saga via ISaga<OrderState>) wrap the enum and > >>> the order to conclude which the current state is? Or should I better keep > >>> this decoupled (and duplicated) > > >>> Sorry for spamming the list & thanks!! > > >>> -- > >>> Jan > > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "Rhino Tools Dev" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]. > >>> For more options, visit this group at > >>>http://groups.google.com/group/rhino-tools-dev?hl=en. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Rhino Tools Dev" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >>http://groups.google.com/group/rhino-tools-dev?hl=en. > > > -- > > Jan > > -- > Jan -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
