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
    yeah exactly
    so maybe the job should send a command like EndSportingEvent
    and then you route that to your aggregate which dispatches SportingEventEnded
    which gets saved etc.
    Rhys Bartels-Waller
    @rhyslbw
    It seems like there's one too many messages in there ;-)
    Dominik Guzei
    @DominikGuzei
    yeah the command would not be saved
    Rhys Bartels-Waller
    @rhyslbw
    When modelling real world domain events
    ah ok getting closer
    Dominik Guzei
    @DominikGuzei
    but the event would, because it is recorded by the SportingEvent aggregate
    Rhys Bartels-Waller
    @rhyslbw
    Maybe the command raised by the job would be better named DispatchStartedEvent
    I'll sleep on it. Thanks so much for your help
    Dominik Guzei
    @DominikGuzei
    hehe, yeah the naming is the hardest part
    you're welcome – great to have someone to discuss these things!
    Rhys Bartels-Waller
    @rhyslbw
    Yes, I'm so glad I found your project. I was getting in all sorts of tangles due to the lack of opinions on how to model things in Meteor
    I'll let you know how I get on with the scheduling. I'm thinking a generic scheduling service is the best option. Let me know if you have any thoughts on namespacing etc
    Rhys Bartels-Waller
    @rhyslbw
    Ok so here's what I'll go with and why. StartSportingEvent and EndSportingEvent. My reasoning is that as you said the SportingEvent aggregate is just a model of something in the domain. In the real world the sporting event does't just start by itself, time dictates that it is underway. In a system it's the infrastructure that manages time, so it is reasonable that it should instruct the model to 'start' and 'end', which mutates state and reports the change which is all we care about.
    Dominik Guzei
    @DominikGuzei
    awesome, that sounds reasonable :-)
    I also thought about publishing generic packages like the scheduling thingy we talked about, as packages
    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 ;-)