We’re in the middle of a massive dev cycle, so while the released packages form part of a stable version, all the good stuff is pre-release. The best way to proceed here is to join our development Slack (send me your email in a private message), as it’s where you can get assistance with concepts or the application of Space in it’s current form.
" how to implement the aggregates and display them in a view”
Event-sourced aggregates publish events that you use to build view collections. We do this using a
If you notice in this project we have separated the domain and application concerns into separate packages. Multiple applications can all depend on the domain context, and it also highlights that an Aggregate knows nothing about display -> it’s up to the application to decide how to interpret the changes into a view state. If this is a bit confusing, just realise that this makes things highly flexible and performant!
"Or is that snapshots?”
Snapshots are a caching feature of the infrastructure, purely for performance when the application is running. When an Aggregate instance is sourced from many events, sending new commands can be slow as it first needs to run through each event to ‘rehydrate’ the aggregate. Snapshots mean that an Aggreagate’s state can be determined by many events, but only not all of them need to be loaded each time a new action is to be taken (usually it’s a command you send)
This is what I have done to successfully run Todos on Mac:
git clone https://github.com/meteor-space/todos.git
MGP output should look something like this:
EBIZMacPro:todos darkomijic$ mgp
HEAD is now at 8b51727 Merge pull request #41 from meteor-space/fix/app-config-bug
Processing space-base at HEAD
HEAD is now at f6c2a9c Merge pull request #16 from meteor-space/fix/application-reset
Processing space-messaging at HEAD
HEAD is now at 8781cca Merge pull request #35 from meteor-space/fix/process-init-via-event-bug
Processing space-event-sourcing at HEAD
HEAD is now at 9b2ac9c Merge pull request #4 from meteor-space/fix/lock-deps
Processing space-domain at HEAD
HEAD is now at efd1caa Merge pull request #43 from meteor-space/feature/improve-missing-component-mapping-error
Processing space-flux at HEAD
HEAD is now at 1978ad9 Merge pull request #16 from meteor-space/feature/contains-array-of-structs
Processing space-testing at HEAD
space-event-sourcing; however please keep in mind that all Space packages are in still in development so its always best to keep track what commit is used by looking on examples like: https://github.com/meteor-space/donations/blob/develop/git-packages.json
npm install -g mgp, this is the part you are probably missing since you get mgp is not recognized), cloned todos (
git clone https://github.com/meteor-space/todos.git),
Hi, I'm looking to "gradually" incorporate some of the meteor-space cqrs/eventsourcing stuff you guys have. My current need is pretty light on business logic, but more on the side of needing to update multiple collections (projections) based on something happening. I've been looking at the test_application.coffee and unit tests. It seems realtively straightforward, but one thing that isn't clear to me is how to handle aggregate initialization. It's probably due to other frameworks I've used (e.g. Axon for Java). So just to be clear, to send a command to MyAggregate(id:123). I first need to create a new instance of MyAggregate (using the id), then call .handle(command)?
It's just a little confusing to me, as say Axon,node-cqrs, basically have you just register all your aggregates, then send your commands to a gateway/handler, that then is responsible for routing, instantiation, etc.
As this is an existing app, I can't quite leverage all the cool features you guys seem to have in your full stack. So for now I just need to send commands from my existing code.
@eoliphan: Hi :)
One instance of the
Space.eventSourcing.Router is routing domain commands to all aggregate instances of the some type. For example this is the router that is routing command to instances of
Router has special
initializingMessage attribute and that is the command that instantiates new instances of the aggregate:
Other commands that are routed to the aggregate instances are defined in
Please feel free to ask more questions if you have them. Also take a look at this sample app, it can help you understand how everything is wired up:
This diagram can serve as a cheat sheet for understanding complete, non distributed Space event sourcing infrastructure: