Skip to content

Episode 27 – Evolving Event Centric Infrastructure

2013 April 12
by Kerry Street

Kerry and Rinat review some of the lessons learned from the deployment of Lokad.CQRS. Then, they discuss Rinat’s blog post about those experiences, and some of his ideas for future improvement. This results in a sneak peek of the new event centric hosting infrastructure that will be used in their GTD sample project.

Download (mp3): Episode 27 – Evolving Event Centric Infrastructure – (41 minutes)

Subscribe via RSS | Subscribe for free in iTunes

Episode References:

What do you think?

8 Responses Post a comment
  1. Kim A. Betti permalink
    April 16, 2013

    Very interesting stuff! Could you elaborate a bit on the glue between the event store and aggregates modelling processes like user registration?

    • Kerry Street permalink*
      April 16, 2013

      The episode we recorded today MAY help to answer this. It will be episode 29 I think. Until then, check out this presentation on the Actor Model as the future infrastructure that we will try out in btw-gtd will be based on that. The key difference is that when applying the Actor Model to our Aggregates, they will be allowed to know how to send messages directly to the “address” of another Aggregate (which happens to be an Actor) instead of needing external “plumbing” to get a message routed from RegistrationAgg to UserAgg for example. (I may be saying this wrong but check out the channel 9 video to get an general idea of where it is headed. You will see that a lot of what we are already doing applies).

      And a more formal description of the Actor Model from Carl Hewitt:

      • Kim A. Betti permalink
        April 17, 2013

        Thank you! I’ve never looked much at the actor model and never thought that it might be applicable here. That’ll be fun to learn more about!

      • April 17, 2013

        Great video! I’m guessing that “addresses” roughly corresponds to what Rinat and Greg calls “links”? I’m curious to see how this address / link table (in lack of a better word) can be maintained. Seems like this would involve some kinda synchronization infrastructure to make sure that aggregates aren’t processing multiple messages at the same time?

        • Kerry Street permalink*
          April 17, 2013

          We talked about Addresses a little bit in Episode 29 and I think I need to see it in code to see how it relates to our Aggregate+ES approach. Because all of our Entities will be Actors, and all Entities have Ids, I asked Rinat how he thought those would relate to “Addresses”. I think I will have a better understanding of his answer when I edit the episode. If I don’t, we can both ask again and/or see it in the implementation to understand it. I am still uncertain about their relationship to links (that didn’t come up).

          • April 19, 2013

            Yeah, using the aggregate / entity id as an address should not be too hard to implement. The tricky part (at least based on my current understanding) is to use addresses to listen in on events originating from other aggregates. Another thing that’ll become more difficult is creating aggregates based on previous events..?

  2. April 17, 2013

    Great video pick and here is another from channel 9 relating to the new ActorFX It should be interesting to see where Rinat plans to take this. The actor model is used in messaging infrastructures and switches so in makes sense that it could be applied A+ES. I hope his plan is to maintain the concepts and core pieces then use the Actor Model to put everything together into a system.

    Since we are on the topic of videos I came across one called the Scaling Pinterest that people may also find interesting.

    Does Rinat have any his ideas up on GitHub? I guess I will have to take a look.



    • Kerry Street permalink*
      April 18, 2013

      Almost all of what we have been doing so far still applies and will continue to apply (we discuss this more in Episode 29). The plan is to make it very easy for Lokad.CQRS users to take advantage of it with minimal change/pain. It seems that the role of the ApplicationService may change a bit but that is TBD. It all sounds very familiar when you hear it. I don’t think he has posted any of the new code to GH yet. Thanks for the links, look interesting!

Leave a Reply

Note: You may use basic HTML in your comments. Your email address will not be published.

Subscribe to this comment feed via RSS