search

Yuppiechef / cqrs-server

An opinionated Clojure CQRS/ES implementation using Onyx, Datomic, DynamoDB, Kafka and Zookeeper.
MIT License
211 stars 13 forks source link

How do you intend this to be used? #3

Closed Folcon closed 9 years ago

Folcon commented 9 years ago

Is this a reference implementation? I only ask because after poking though the codebase it appears that I'll have to reimplement the core and module namespace. Core because it's mostly configuration data and module because that's where the messaging is defined.

Just trying to understand what your plans are :).

CmdrDats commented 9 years ago

You've hit the nail on the head there :) After developing it a while, I realized that it's really just a specific configuration of Onyx, not much more. I have plans for developing some other surrounding pieces into it, like the event listeners, some reference ETL implementations, callbacks (for a complete loop comms process), profiling and monitoring infrastructure and simulation testing.

Really though, the core (as in: cqrs.clj) will be always rather small, so this is meant to focus on getting all the machinery in place and solid to be able to implement an app on top of it and be able to test this level independently of an actual app implementation.

It's also (as you mention 'reference') to be a blueprint for all the decisions you need to make as a developer when you build a module - The idea is that once you've made all the design decisions and implemented the bit, you should have a mostly complete module going.

Folcon commented 9 years ago

So for what you've described it looks good, there are still some parts missing I feel. Monitoring/Simulation testing would be great. Do you want to leverage something like simulant?

I can certainly feel the pain of not knowing what's happening at present if I pass an wrong message or the system errors. I hooked it up to onyx-dashboard and was disappointed to see it didn't pickup failures.

CmdrDats commented 9 years ago

Simulant is definitely on my radar, though I need to wrap my head around some of the implementation details - It feels a whole lot more intense than I need it to be, but that might just be an educational problem.

I am wanting to incorporate some kind of interaction modelling aspect into the modules so that you can specify how the module fits into the rest of your system, how states flow and define generators so that it can throw generative data around for load testing and generative testing purposes. This does imply an abstraction dealing with multiple modules loaded at the same time - basically glueing your entire system together.

I definitely share your pain regarding the 'blind' feeling - I have a couple of ideas brewing.. In particular, I would like some kind of automatically generated report that highlights flow (lots of success flow = good and green, exceptions reported or no outflow = probably bad and red).. but I'm all ears for feedback in this area.

That said - the Onyx Dashboard is still fairly young, but the Onyx guys have some pretty big plans with it which will likely help ease the pain a bit.

Folcon commented 9 years ago

I'm more than willing to provide feedback, I've found the onyx chat channel, so I'll try and stay active there.