I'll try to answer your questions with an example (omitting the updateState
pattern):
1.
val receiveCommand: Receive = {
case ChargeCreditCard(payload) => {
// Enforce business rules, constraints, etc.
if (isNotEnough(payload.amount)) sender ! "Can I haz more?"
// Some rule violations might trigger their own events
if (looksFake(payload.creditCard)) {
persist(PossibleFakeCardEncountered(...)) { _ => fraudSuspected = true}
sender ! "Please stay where you are, local authorities will be there any
minute."
}
// If everything's okay do the actual work
var charged = Try(paymentGateway ! charge(payload.creditCard,
payload.amount, ...))
// Once the work is done, change state (if nesessary) and persist the
event(s)
charged match {
case Success(_) => persist(CreditCardCharged(...)) { _ => paid = true }
case Failure(e) => {
persist(PaymentProviderMessedThingsUpAgain())
sender ! "There was an issue, please send a check."
}
}
}
val receiveRecover: Receive = {
case CreditCardCharged => paid = true
case PaymentProviderMessedThingsUpAgain => // no state change needed
case PossibleFakeCardEncountered => fraudSuspected = true
}
The important thing here is that the command handler (receiveCommand)
guards against invalid input, checks business rules, enforces constraints,
does the actual work and emits events. The event handler (receiveRecover)
does nothing but change state according to the received events. You
wouldn't want to charge a credit card every time you rehydrate the actor
from the event store.
Hope this helps,
Dennis
On Thu, Jul 31, 2014 at 9:19 PM, Konrad 'ktoso' Malawski <
konrad.malaw...@typesafe.com> wrote:
> Hi George!
> I’ll start with the infameous “it depends”, but let’s get into a more
> constructive answer :-)
>
> As updateState is not really something akka forces you to do - it’s simply
> a pattern we’ve found to be useful.
> The core of it is “a method which you can call from both `receiveCommand`
> and `receiveRecover`”.
> I’d split methods in terms of “does interactions with outside world and
> should not be triggered on recovery” and “does not trigger interactions
> with outside world”.
> But for example if you create child actors as part of your domain logic,
> you will want to trigger this during replay - to be ready for an incoming
> request which needs them etc.
>
> I for one would not put much logic into events. I tend to keep them as
> simple as markers that “stuff happened” - when actions need to be made, I’d
> use actors to do them. Putting a require() or two in there may be ok, but I
> wouldn’t put more complicated stuff into an event - it’s some actor that
> would “perform” the work.
>
> As for commenting Martin’s quote, by Command he means “incoming message”
> (as does our PersistentActor#receiveCommand), and by Event he means “the
> event that the Persistent Actor has persisted, as effect of that incoming
> command”. This means: command comes in, apply some logic to it, store
> “result” of that logic as event (SignedUp / UserNameTaken etc.), and act
> upon this event (once it’s persisted safely). So the logic leads to storing
> of events.
>
> I hope this helps, feel free to ask more or give examples of what you’d
> need :-)
>
> Happy hakking!
>
> --
> Konrad 'ktoso' Malawski
> hAkker @ typesafe
> http://akka.io
>
> --
> >>>>>>>>>> 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.
