Roadmap for first release

nvivo commented 9 years ago

Things to do before releasing the first alpha:

[x] Finish the logic for the Query mechanism
[x] Implement the CommandProcessor
[ ] Have InMemory, MySql and SQL Server backends working with tests passing

nvivo commented 9 years ago

Having only sundays to work on this, so it's taking longer than expected. Hopefully next week I'll have the first nuget package.

promontis commented 8 years ago

From the title it looks promising! Exactly what I've been looking for. I'll have a more detailed look today... anyhow, keep up the great work!

ps: perhaps you can think on added some todos to the issue list. That way I could contribute if you'd like.

nvivo commented 8 years ago

@promontis that would me amazing. I have been quite busy with a company project that is consuming my time entirely, and have not been able to concentrate on finishing this. I'm eager to get back on this as soon as I can.

At this point, things seem to work with the in memory store. I just want to finish at least one of the sql backends so we have something to publish that can be persisted. My initial idea was to have something like NEventStore.Persistence.Sql where a single implementation could be shared across many sql databases just by changing the dialect. My initial implementation was based on my experience with mysql where building raw sql strings gets to amazing insert speeds. But it turns out abstracting this way is terrible for other databases like sql server.

Right now, I'd like to have a simpler implementation of the BaseSqlStore that doesn't rely on building complex sql strings. Possibly using independent inserts or prepared statements with parameters just to make it easier to extend to other databases.

Once that's done, I can publish a nuget package and focus more on documentation and getting it stable.

If you wanna try changing or reimplementing the sql store, would help a lot. I can help with the details if needed.

promontis commented 8 years ago

@nvivo Reading the source code bit by bit now. Could you tell us something on the difference between Akka.Persistence and this project, and why you made them?

nvivo commented 8 years ago

@promontis. I think we have different views and goals. Akka Persistence defines event sourcing as actors replaying events to rebuild state before processing commands. But it seems to me this is a very limited view of the paradigm.

First, in Akka Persistence there is no good story for querying events in a generic way. It handles each stream independently in each actor and provides no simple way to query different streams and merge the results for example (like EventStore projections). There is a very long discussion here to solve some of these issues, but even if that's implemented on JVM (it wasn't when I started writing this code) and ported to .NET, it's still a limited API to do what I wanted to do.

To me, it looks like akka persistence works very well in examples or if you're using only to persist actor state (which is it original goal), but if you really want to benefit from event sourcing, it's a very small piece of the puzzle. Since what Akka Persistence does is relatively simple compared to some other goals like querying and projections, I decided to skip it completely and just build from scratch.

A few major goals that are not part of persistence are:

A generic way to query events from any stream like EventStore does - currently, projections filter event types, but there is nothing in the architecture that prevents having lambdas to analyze the content of the event to build the projection
I wanted to be able to write some events without replaying anything - some events don't depend on history - if someone clicked that button or opened that email, I just wanted to append the event to the end of some stream without overhead.
A simple and built-in way to build projections on external databases - so you can optionally have query data on mongo, redis or sql for querying withoug having to deal with the syncrhonization process

There is more, I plan to have some more docs with goals and roadmaps once I have the time.

But in the end, I guess I wanted to have a more opinionated framework you can really build an application on top of it using event sourcing, instead of it being a low level tool.

DamianReeves commented 8 years ago

I'd also like to contribute as I have a need to build a CQRS/EventSourcing framework on top of Akka. A todo list would be great. One immediate item that would help is to setup a build process that produces nuget packages, even if you aren't ready for those packages to be publicly available, but I see no harm in 0.0.1.0 packages which are early work. I'll add an issue for that and use that to discuss the build framework (i.e. FAKE, Cake, or whatever).

nvivo commented 8 years ago

@DamianReeves I'll see if I can write down some of the things I have in mind this weekend. Also, if you have ideas or needs, please open issues and we can discuss how to implement that.

nvivo commented 8 years ago

I just published an initial package to nuget as it is, only with InMemoryStore support to get things going.

https://www.nuget.org/packages/Even/

Any further discussions should go to new issues.

Rajivhost commented 8 years ago

Great, let's play with the first alpha!

DamianReeves commented 8 years ago

Great news, this should start moving things forward

evendotnet / Even

Roadmap for first release #2