Konard, Thanks again.
I understand one actor per aggregate root wrt to DDD. But I am stuck in this problem. I don't want take the approach of inter aggregate root communication i.e. one aggregate root will do it's CRUD and will forward the next CRUD request to second aggregate root and so forth. If one of the aggregate root fails to do CRUD, a corrective event/rollback event has to be raised. Which will make it complex process. Most of the times not the correct approach. Will go through article shared by you, hope so :) it should help solving my problem. If you have any solutions it can be great input. Have a fun weekend and it was pleasure discussing with you on distinct topics. On Friday, 8 August 2014 20:29:25 UTC+5:30, Konrad Malawski wrote: > > There is no "global transaction scope" – you're in a lock-less > asynchronous distributed system, can't beat the CAP > <http://en.wikipedia.org/wiki/CAP_theorem>. > > I highly recommend watching this talk by Eric Evans about "Acknowledging > CAP at the Root - in the Domain Model > <http://www.ustream.tv/recorded/46744749>" from this year's CRAFT > conference in Budapest. > I really like this talk because it shows how not only you can model your > domain to fit into this model, but actually it often "fits" this way of > thinking. > > Our PersistentActors can be viewed as Aggregates (wording used from "the > DDD book > <http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215> > "). > An aggregate can guarantee that the invariants that it checks are always > valid. > You cannot do a hard guarantee like this between aggregates (well – you'd > have to lock the world, check your things, unlock the world – we don't want > to do that). > > Have fun watching the talk and enjoy your weekend :-) > Happy hakking! > > > > On Fri, Aug 8, 2014 at 3:56 PM, Prakhyat Mallikarjun <[email protected] > <javascript:>> wrote: > >> Hi, >> >> I was looking for using single writer principle in our architecture for >> domain object persistence. Want to use event sourced persistent actor >> sharded in akka cluster by particular algorithm(ex. by particular ID), >> which will make sure CRUD's for *A* domian object happens through only >> one persistent actor. >> >> A simple use case i.e. CRUD for A domain object can go through single >> writer. But consider a situation, if business evaluation requires to change >> multiple domain objects in one stroke, *what should be the solution?* >> >> Lets take this example, 3 domain objects belonging to 3 different single >> writers have to be changed in one stroke.In this single writer wont help, >> as all 3 domain object updates will go through *3 separate single >> writers*, and *will not be in one transaction*. >> >> Is it possible with event sourcing to involve *different/multiple single >> writer's in one transaction scope*? >> >> -Prakhyat M M >> >> -- >> >>>>>>>>>> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Cheers, > Konrad 'ktoso' Malawski > hAkker @ Typesafe > > <http://typesafe.com> > -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
