Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dominik Guzei
    @DominikGuzei
    this would be perfect real-world examples of how to use space-cqrs but you don't have to expose your whole app
    Rhys Bartels-Waller
    @rhyslbw

    Can you elaborate on "but you don't have to expose your whole app” ?

    What about a new space package, space-queue that sets up the job-collection, which the snapshotter, scheduler, and cache rebuilder all use? space-workers are isolated in their own package would observe the queue and complete jobs when they are triggered via observers on the job-collection.

    Rhys Bartels-Waller
    @rhyslbw

    Or an infrastrucure package (space-infrastructure) with classes queue, worker, scheduler, snapshotter, rebuilder ? That would be more flexible, and allow for configured background apps to achieve specific goals

    class SnapshotSportingEvent extends Space.infrastructure.snapshotter
        schedule: ‘every day at 0300’
        maxEvents: 100
    
       eventStream: ‘SportingEvent'
    class Space.infrastructure.snapshotter extends Space.messaging.controller
        Dependencies:
            queue: 'Space.infrastructure.queue'

    ?

    Rhys Bartels-Waller
    @rhyslbw
    Actually no forget Space.infrastructure. Snapshotter fits nicely as part of the cqrs package as it can work in the same process, or potentially outside the main process with the queue.
    Rhys Bartels-Waller
    @rhyslbw
    Hey also what’s your development workflow look like? I notice you only have a master branch in the repos.
    Rhys Bartels-Waller
    @rhyslbw
    @DominikGuzei I’m seeing a difference in the way you route messages and the use of process managers compared to the microsoft Journey material. Wondering if you have a moment to discuss?
    Dominik Guzei
    @DominikGuzei

    Hey @rhyslbw sorry for the absence, I was away from the laptop for the last 3 days ;-) I will travel to Barcelona today, so unfortunately there is not much time either – tomorrow could be a good time!

    To answer your question: Yes, there are many different implementations floating around the DDD + CQRS community. I chose an approach where Sagas/Process Managers are also just event-sourced Aggregates with one additional capability: sending commands to orchestrate other parts of the system. So in space-cqrs process managers are also just domain-level objects that have no idea about the infrastructure (message routing, persistence etc.). I also realized that this has drawbacks in some situations. For example, you need extra events to persist the state of the process manager which sometimes have ugly names like CustomerRegistrationEmailRequested. At the same time I like the concept that processes are first-class domain concepts.

    Rhys Bartels-Waller
    @rhyslbw
    Hey no worries!
    Thanks for the info, makes a lot of sense. ProcessManagers are special aggregates
    Maybe they can just be named Processes?
    Dominik Guzei
    @DominikGuzei
    Yeah good idea – i kind of liked Saga because its short and sweet – but it means something different in DDD
    Rhys Bartels-Waller
    @rhyslbw
    Just like we should use the terminology ‘Saga’ only when crossing aggregate boundaries
    haha
    with transactional compensations
    Dominik Guzei
    @DominikGuzei
    yeah, more complex scenarios
    I like Process because manager is pretty generic anyway
    Rhys Bartels-Waller
    @rhyslbw
    Yes it’s superfluous if you think about it
    like “service”
    Dominik Guzei
    @DominikGuzei
    yep, i just copied from the microsoft journey ;-)
    Rhys Bartels-Waller
    @rhyslbw
    I’m actually working through that now
    The other issue I’m struggling with is the handlers
    Part of me wants to just be calling methods in the aggregates rather than routing a command through
    Dominik Guzei
    @DominikGuzei
    the problem is this: you need some layer of authentication etc.
    Rhys Bartels-Waller
    @rhyslbw
    Dominik Guzei
    @DominikGuzei
    this does not belong into the aggregates
    also, you can't keep all the aggregates in memory (like the handlers)
    Ok, I have too leave now – but we can continue the discussion tomorrow!
    Rhys Bartels-Waller
    @rhyslbw
    Right, so you would have to pull the aggregate into memory to then call the aggregate’s method from the controller, which in that sense is more of the traditional comamand handler?
    Yep no worries, this has been a big help. Will be more informed for our next chat!
    (I like the controller acting as a router)
    Rhys Bartels-Waller
    @rhyslbw
    Ah I just read this from the MS Journey "We use the term handler to refer to the classes that handle commands and events and forward them to aggregate instances, and the term router to refer to the classes that handle events and commands and forward them to process manager instances.” Makes sense, I might adopt the same style
    Dominik Guzei
    @DominikGuzei
    Hey ho! I am back from holidays ;-)
    Dominik Guzei
    @DominikGuzei
    Hey @rhyslbw, do you have any tips for interesting Meteor jobs? I am looking for some short-term project from now to mid-July, 20-30 hours a week.
    Rhys Bartels-Waller
    @rhyslbw
    This message was deleted
    Rhys Bartels-Waller
    @rhyslbw
    Welcome back! Let’s chat privately about that
    Rhys Bartels-Waller
    @rhyslbw

    So based on the discussion we had relating to the Space.cqrs.ProcessManager and some more research I’m in favour of reworking it based on the State Machine pattern. Here’s a good excerpt from the MS Journey project:

    "In this bounded context, a process manager is a class that coordinates the behavior of the aggregates in the domain. A process manager subscribes to the events that the aggregates raise, and then follow a simple set of rules to determine which command or commands to send. The process manager does not contain any business logic; it simply contains logic to determine the next command to send. The process manager is implemented as a state machine, so when it responds to an event, it can change its internal state in addition to sending a new command.

    Our process manager is an implementation of the Process Manager pattern defined on pages 312 to 321 of the book by Gregor Hohpe and Bobby Woolf, entitled Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Professional, 2003). “

    Dominik Guzei
    @DominikGuzei
    Ahoi! Yeah let's do it like that – I In the first step, I would suggest that we strive for a very basic implementation of the state machine pattern without any bells and whistles. Then we can try it out in an real-world scenario and work from there.
    Rhys Bartels-Waller
    @rhyslbw

    Have you read these articles? Given the state machine pattern still needs to record a log, maybe it is better to retain event sourcing as the persistence, but instead of just extending the aggregate, the event sourcing functionality be extracted that can then be extended by the Aggregate class and the Process Manager class

    http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-i-of-ii/
    http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-ii-of-ii/

    That way the ProcessManager doesn’t end up with Aggregate concepts, and it can be expressed with methods like Transition, Configure, PermitIf
    Rhys Bartels-Waller
    @rhyslbw
    *Aggregate concepts like handling a command…
    If the methods abstracted the boilerplate code required for event sourcing, it would seem that the ‘overhead’ is no longer a problem.
    Dominik Guzei
    @DominikGuzei
    Yeah I've read both and that was actually the reason i implemented the process manager with event sourcing.
    Of course we could extract the basic functionality, but i am not sure how much benefit it would bring as the first step. It also wouldn't solve the concern of "boilerplate events" – they are not boilerplate but in many cases it feels like a lot of overhead to model even the simplest concepts
    but i guess that's a general problem with event sourcing, it has long-term benefits but brings a lot of tiny overhead-tradeoffs to the table
    Rhys Bartels-Waller
    @rhyslbw
    I guess by boilerplate I actually mean we could focus on making the API more expressive rather that it just being a generic event handler with the ability to trigger commands and maintain state.
    Which could initially be done by experiements directly within the ProcessManager class, then later if it makes sense, revisit the class it’s extended from
    Dominik Guzei
    @DominikGuzei
    yeah of course, that's something we can improve step-by-step ;-)
    Rob Landers
    @withinboredom
    Hello...
    Rob Landers
    @withinboredom
    Have any of you guys hooked this up to distributed queue, like SQS, IronMQ or Azure ServiceBus?
    Rhys Bartels-Waller
    @rhyslbw

    Hey @withinboredom. No but the latest space:messaging includes a basic custom queue using Mongo. It’s undocumented right now but check this commit for changes and tests CodeAdventure/space-messaging@aa286c7

    It’s brand new and I’ll be starting an implementation using it later today