If you want to build apps without accidental complexity that are easy to reason about and test then you should be using meteor-space set of packages https://github.com/meteor-space/event-sourcing. Meteor-space will introduce you to the wonderful world of event sourcing and CQRS (command query responsibility separation) and why it is awesome way to build maintainable apps https://youtu.be/JHGkaShoyNs. Have questions? We are here https://gitter.im/meteor-space/general Example app here https://github.com/meteor-space/example-app-event-sourced-shop
7 Likes
You know, this is probably the tenth time I’ve taken interest in getting to know the space-* line of packages and what you are trying to or indeed have achieved.
I must admit I have a keen interest in this and believe there is some really valuable gem lying around hidden in there, hidden being the operative word.
Don’t get me wrong, the readme’s and the wiki articles and all those external links sure amount to some hefty knowledge, but it is really hard to pick somewhere to start, let alone draft out a learning plan.
So, I’d really really really love to see
- A series of 3-5 blog posts that walks a gentle introduction through to final links to advanced literatur
- An accompanying app (yet another blog example) that’s referenced in the blog post
8 Likes
Wow, thanks for your feedback @serkandurusoy – it’s good to know what is missing for newcomers!
When you work with the framework everyday and the concepts / building blocks are second nature, it is really hard to understand where the documentation needs improvement.
To give you a glimpse of hope: We already discussed in the Gitter group that we will port this awesome CQRS/Event Sourcing tutorial to meteor-space, complete with event-sourcing and reactive UI using space:ui (Flux / React concepts). The tutorial will definitely give you a good overview how the various space-* packages work together and provide all neat abstractions and tools to build well-tested and maintainable large-scale Meteor applications. You can expect this tutorial to go live within the next few weeks!
Regarding the general documentation, we are well aware that a lot of work has to go into that and we are happy about all suggestions or even pull requests to improve the situation 
Finally, don’t hesitate to join our general discussion at Gitter where you can ask any question and usually will get a good answer within a few minutes to (max) some hours.
2 Likes
These are definitely good news.
Given that most devs are (had been) complaining about meteor “force feeding” its choices such as mongo and blaze to developers, and in light of recent abundance of especially front-end alternatives, I’d really like to learn how the space-pieces fit together and which ones I can swap out in favor of “x” should I choose to.
Also, CQRS/Event Sourcing is actually a great solution to a heated problem currently being discussed, so perhaps you might want to chip in.
2 Likes
Ok, so basically you can think about Space being a meta-framework for organizing all the details of your application. It deliberately does not force you into a single stack of Meteor packages, but guides you to structure your app in a way that all the little pieces (think: router, ui-framework, anything else …) can be swapped out with minimal effort, even while running your application. It really tries to evangelize the interfaces over implementation design pattern.
It helps you with decoupling by following best practices in regard to separation of concerns and the single responsibility principle, so you never mix up concerns like routing / data subscriptions or view components in a single component of your application. A good example of the Meteor community is how many people wrote apps that completely relied on iron-router. If they had used clean separations, the switch to flow-router (or anything else) would have been a 30 minute refactoring, because 99% of your app should not know about routing at all!
So please don’t expect another framework telling you how to couple together various concerns because it is so hip to use template subscriptions now. The core of space is really simple: It provides you with tools and some structural guidance to build testable and maintainable Meteor apps. It simply is the boiled-down experience and learnings from fighting with flawed Meteor principles (or promoting the good ones) from the standpoint of a testing freak (me). Nothing more, nothing less.
PS: thanks for the link, i chimed in
3 Likes
AFAIK this is the only way to craft a Meteor application with CQRS principles and Event Sourcing the system’s state. Getting involved with this project and small dedicated community is highly recommended, particularly if you are building an app that is even slightly more complex that modelling a few concepts. There are tools in the library that will allow for structured approach in both the UI and domain layer, and in some cases capabilities that would be impossible without.
For now dig into the tests directories of each repo, and gain understanding of the concepts relating to the architecture, from general DDD, CQRS, Event Sourcing, Task-based UI, React/Flux, messaging, and most important testing! We’re working on improving the APIs to be more expressive, and abstracting things where patterns emerge.
We often say how suited Meteor and Mongo are for this style of architecture, no it’s not perfect, but damn it’s pretty close! Come join us if this peaks your interest 
3 Likes
Looks very interesting. I’ve done a lot of CQRS in the JVM world, with Axon for Java, as well as EventSourced/Akka Persistence for Scala, and as cool as Meteor is, not having some first class support for event sourcing ,etc was sorely missed. I’d looked at trying to port the node-cqrs, etc packages over but that was time I didn’t have
FYI, check out Axon (if you havent already), all the stuff isn’t necessarily applicable in the Meteor world, but it’s pretty complete in terms of features, and you may want to add some to your roadmap
1 Like
@CodeAdventure: @Sanjo and I been doing some research for our automated testing best practices repository, and we are coming to the same conclusions as you, that the combination of DDD, CQRS, EventSourcing, React and Flux are all fantastic building blocks to tame complexity, and that they make it simpler to discover the domain through testing.
Our journey has come about from wanting to test drive development using the Modeling by Example technique, where we go Domain inwards, unit testing almost everything, then we test the critical paths using the UI. This approach creates the perfect testing pyramid without any extra thought. You simply follow the technique and the balance is achieved. That speaks a lot about the techniques legitimacy.
First we had to separate the domain concerns from the UI concerns. We managed to encourage that by getting Chimp to run a two-stage process. First it runs domain tests, then it runs @critical (UI-based) tests, and we can use different directories to store different implementations of the same step signatures. This is working nicely and has streamlined how we focus our efforts when working on new features.
Now we are trying to separate the infrastructure concerns (persistence) from the modeling concerns (the core). We are currently using Astronomy and I’ve managed to use Chimp to exercise the domain objects and the services directly without persistence (win), but I hit a bit of a block when going through the UI again, and I found myself having to do the persistence in a “controller” layer. While that’s a valid way to do it, it gets nasty when lots of domain entities are changed, especially with deeply nested changes.
After some research, I ended up finding the same resource you found (completely separately), and I’ve realized that to separate the persistence from the domain, we need to rethink the architecture to use something exactly like event sourcing and CQRS. It looks like you guys have already started on doing this with Meteor so I’m very happy to see it!
As soon as I saw the the cafe example the Edument guys came up with, I immediately thought to replace the current bank app (yuck) that is in the best practices repo. Since you mentioned that:
I would love for us to collaborate (however it makes sense to) on porting this awesome example, and to add Modeling by Example to it using Chimp. Thoughts?
PS: We already got Wallaby working on the React components and we have realtime instantaneous test feedback while coding. It’s awesome! We’re almost there with getting it working for app code too
3 Likes
Hey @sam and @Sanjo, that’s really great news!
@rhyslbw, @darkomijic, me and others are already building their first apps based on DDD, EventSourcing and CQRS using the space:event-sourcing package. I’d like to publish the next major release asap, definitely before February – together with the other base packages.
Im really looking forward to get my hands on the new chimp workflow and trying domain layer testing with Gherkin too. I guess we should start a discussion, setup a trello board etc. to coordinate our efforts This will become a top-notch professional setup for serious, maintainable business apps with Meteor!
Do you think the Space slack channels are a good base camp for that? Im open for any suggestions!
3 Likes
Trello + Slack sound great. I’m already on the slack channel so let’s keep talking
1 Like
Here is the architecture diagram for sample app Todos which can help understanding Space architecture until work on new documentation is complete.
Ok so here’s a quick summary of the current state relating to this thread:
-
space:domain provides generic DDD building blocks:
EntityValue ObjectEventExceptionCommand
-
space:event-sourcing provides infrastructure and ES specific domain objects:
AggregateProcess
While aggregates and processes are DDD concepts, they only make sense to be concrete ‘classes’ in the context of ES (at least in our case), since they are just entities given the interfacing responsibility over a cluster of domain objects. Event-sourced aggregates do need special behaviour, such as recording state change events to an in-memory queue ready for saveing to the commit store by the infrastructure.
Make sure to follow along in the Github repos and get in touch with any questions or issues via the relevant channels. These libraries are supporting some big projects, which the developers are networking via Slack. We’re preparing for a major documentation push, but don’t let that stop you if this is a critical part of your next project, we’re here to help in the interim.
3 Likes
So, did this awesome effort die out slowly or did some other project run with the torch on event sourcing and DDD?
It was one of the most interesting project in meteor community but died. I switch to nest.js for cqrs.
I think module system in meteor is enough for many projects. You can find my example examples/complex-todos-svelte at main · meteor/examples · GitHub
1 Like