Hi Vaughn Thanks so much for replying. I have your excellent book and the Blue Book, but obviously I'm still a bit unclear on some things.
> > So you are giving unique identity to Domain Events? That sounds less like > Event Sourcing already. While that can be done (and my book discusses it), > it might make using Event Sourcing more difficult. Perhaps actually what > happens is that GenerateAlert and UpdateAlert are only Aggregates and not > Domain Events, but when they take on a new/modified state they produce new > Domain Events. This would allow you to make the Alerts persistent and leave > Domain Events as facts that you never query on their own. > No, what I was calling domain events are just Akka messages, though they're published to an Akka EventBus. Currently, the Monitor actor (which is stored in an RDBMS) just publishes a message, and an AlertWriter subscribes, but that will have to change if I want to ACK the write before updating the state of the monitor. > If Monitors and Alerts are both Aggregates, does it help ease this > situation? > Currently they each have their own table. I do need a read model for Alerts. > At this time, and Domain Events that you generate from your > PersistentActor are durably persisted. These also become part of your actor > state, and if you want to persisted Event to be delivered specifically to > another actor you should use AtLeastOnceDelivery. Otherwise, it work work > as you indicated. You would not see do generated Domain Events until the > View receives them. At that time they could be used to project views, to be > sent to other actors such as Pub-Sub, etc. Just to be clear, any > Command/Event/Document Messages that are sent to an actor are not durable > by default. Using ! to tell an actor something is always just > at-most-once-delivery. (This is changed from the previous persistent > channel support, and as far as I know it's going to stay that way.) > I believe there's a section in your book where you talk about the value of a domain event log even if you aren't doing event sourcing, and this log becomes the out-of-band input to JMS, Kafka etc. Here it sounds as though you think of the events Akka persistence stores as domain events, and for the purposes of updating other aggregates or BCs, something would "subscribe" to the journal, rather than the source aggregate "raising" an event. > > Do you agree that making a distinction between domain events and aggregate >> persistence events is useful even in an event sourced world? >> > > If I understand you, you are talking about a third/forth way to deal with > Domain Events, where the Event has business domain identity. That's > different from Event Sourcing and different from what I discuss in my book > and in the blog post you reference. > I think I'm just a bit confused. Events used to rebuild aggregate state seem subtly different from events used to notify dependent aggregates or BCs. I was wondering if the term Domain Event should be reserved for the latter. I'll re-read the section on AtLeastOnceDelivery, though it's unclear to me whether it will be part of the 2.4 version of persistence. > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
