I think you would be pleased using Scala, and at first just treating it as
a better Java until you are more comfortable with it. To demonstrate the
code enconomy you will get, consider this:
import scala.util.{Success, Failure}
(actor ? message).onComplete {
case Success(goodMessage) =>
Look at Akka Persistence and its PersistentActor trait. Also if you need more
guidance you can see my book: "Reactive Messaging Patterns with the Actor
Model".
Vaughn
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>>
Okay, I will see if we can update to 1.8 from 1.7. Thanks for the detailed
explanation.
Vaughn
--
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
---
As a rule you should never delete messages/events from the store. I am not
sure of the original motivation for allowing deletes, but for event
sourcing it shouldn't happen ever.
Vaughn
On Thursday, July 23, 2015 at 6:52:32 AM UTC-6, Anders Båtstrand wrote:
Dear group
I am quite new to
Hello Avi,
I find several things in your example questionable, and basically not well
modeled. You seem to be taking for of a technical approach to your model
and probably not having conversations with domain experts. Does your domain
expert really refer to VehicleAggregate, UserAggregate, and
My upcoming book Reactive Messaging Patterns with the Actor Model
discusses the use of PersistentView to support a Durable Subsriber.
On May 10, 2015 4:00 PM, Alejandro López ale64...@gmail.com wrote:
@Olger Thanks for the detailed explanation of your approach. As Richard
mentioned, it looks
Hi Anil,
I provide the Aggregator pattern and approximately 60 others in my upcoming
book Reactive Enterprise with Actor Model. It's written for Scala and
Akka, and you can see the preview here:
https://www.safaribooksonline.com/library/view/reactive-enterprise-with/9780133846904/
Best,
These are all really great questions. I will provide answers as I
understand them and as things currently stand. In another thread Roland
discusses the Akka roadmap for the next half year. It's possible that some
things could change between now and then, so I can't say that this is
long-term
If you are doing Event Sourcing the Domain Events are both your state and
the means by which others are notified of changes. Because with Event
Sourcing you need to create new events for everything that happens in your
Aggregates you may not want all of those events to be published to
Have you considered using Cluster
Sharding? http://doc.akka.io/docs/akka/2.3.7/contrib/cluster-sharding.html
Vaughn
On Tuesday, December 16, 2014 9:24:50 AM UTC-7, Chris Campbell wrote:
Hi-
I am setting up a cluster and want to instantiate actors of the same type
with unique identities.
Yes, good idea, Roland.
I also want to make the list aware that my new book Reactive Enterprise
with Actor Model is now available as Rough Cuts on Safari Books Online:
https://www.safaribooksonline.com/library/view/reactive-enterprise-with/9780133846904/
If you don't already have an
Hi Ashley,
Personally I'm having a little trouble understanding how your three points
differ much. Couldn't you extend PersistentActor as something like
TopicEnricher and make it's enrich method call persist? I see your need,
but I think it's enough out of the scope of ES that it is probably more
Hi Roland,
It's a good summary. As far as I can see it looks very complete and allows
for a lot of flexibility between scalability and ease of use.
I will add that I am interested to see Martin's causal consistency with
zero application-specific hints or code (unless its just obvious previous
FWIW, Chronicle has almost the same meaning as Saga, and I am pretty sure
that Chronicle is not used in any way that is associated with processes.
That said, I am actually not recommending that the name Process Manager be
substituted by Chronicle. I am just throwing the name out there.
I am
need we’ll ticket and solve it, as usual ;-)
Regards,
Roland
12 aug 2014 kl. 18:10 skrev Ashley Aitken amai...@gmail.com javascript:
:
Thanks for your post Vaughn.
On Monday, 11 August 2014 05:57:05 UTC+8, Vaughn Vernon wrote:
None of this stuff is easy to do, and even harder to do
Can someone (Martin?) please post some rough performance and scalability
numbers per backing storage type? I see these DDD/ES/CQRS discussions lead
to consumer-developer limitations based on performance and scalability, but
I have not seen any actual numbers. So please post numbers in events
at this time.
Vaughn
On Thursday, August 7, 2014 1:29:33 PM UTC-6, Patrik Nordwall wrote:
7 aug 2014 kl. 20:57 skrev ahjohannessen ahjoha...@gmail.com
javascript::
On Thursday, August 7, 2014 7:34:15 PM UTC+1, Vaughn Vernon wrote:
I vote that you need to have a single sequence across
For the service discovery part, it might help to consider the old Jini
model. I was going to work on this some time back, but ...
Not that other ideas here aren't valuable, but I think that Jini got a lot
of things right. Unfortunately JEE caught the limelight.
Vaughn
On Monday, June 2, 2014
Why not use a business-level identity as a correlation id that travels
through the processing and view compositions that you describe? In the end
you could use an EventBus to tell a given presentation that its newly
composed view is available. You might find your answers using something
like
You might find these references helpful:
- Aggregator: https://vaughnvernon.co/?p=539
- Scatter-Gather: https://vaughnvernon.co/?p=561
On Thursday, May 1, 2014 6:51:03 AM UTC-6, Richard Cole wrote:
That's a really interesting proposal, would you recommend that the master
still handles the
Hi Patrik,
My December didn't go as planned and I am just getting back to this a
little, among several other things. Did you build a jar for 2.3-M2, or do I
need to build one locally?
Vaughn
On Tuesday, January 7, 2014 12:47:10 AM UTC-7, Patrik Nordwall wrote:
Hi Richard,
The actors as
21 matches
Mail list logo
