Blueprint idea about event-sourcing HOT 6 CLOSED

Like the idea on how to actually do this / see how you approach those. But wasn't this whole discussion about "people should not adapt the one provided style but use their own" the reason to move away from providing a template / framework?
I think those should be included in the two example projects and reflect the structures used there. Better supports the story of 'use your own patterns' while still being available for inspiration :)

from event-sourcing.

people should not adapt the one provided style but use their own

yeah, but we said that we want to provide a blueprint for those who don't know where to start.
The blueprint should not be composer installable but only be available as copy and paste so that people own the code and can adapt it whenever they feel the need.

There are a few flavors and I hope we can highlight the most important ones. You have to make some choices, but if you're new to Event Sourcing those details might scare you.

I try to provide an example soon so that we can better discuss pros and cons. An alternative could be that we say: prooph focuses on advanced event sourcing only, with the best event store available for PHP but not more. And we redirect all new users to either Event Machine or EventSauce and spend our OSS time on a stable event store + advanced CQRS / ES knowledge transfer.

I will definitely reuse and link to Event Machine docs (because I wrote them ;)) and use the new Fee Office domain for prooph docs as well.

Side note: Whenever possible I use Event Machine these days. The way it works fits perfectly with the way we need and want to implement projects: Extremely fast, but reliable and sustained development. This means that prooph/event-sourcing has no longer enough value for my team and I can't spent much time on maintaining it. If we want to provide something for the larger community, this definitely needs to be community driven. Small tutorials on how to implement and customize an event sourcing layer are hopefully the right way. I want to avoid all those discussions like: is prooph better or worse than other implementations? Is the project still actively maintained? I cannot do XYZ with prooph, can we open the API? .... This is all a way too much time consuming and since we use our own style (prooph software team), we are not really interested in any of these questions anymore.

from event-sourcing.

+1 for the idea. Although I agree in concept with reducing as much as possible the ties with frameworks at the domain level, having to recreate this for all projects, or within a larger company is too much. Not to mention the learning curve of the trial/error cycle for something that could be thought as a commodity.

Having a working blueprint (more then buttercup) with their pros and cons would help a lot imho. Focus the event sourcing with one event store (your own, or eventstore.org etc) and leave for the community to write adapters for the the others they want.

from event-sourcing.

I use PHPStorm live templates heavily and tried custom class templates (file templates) recently. You can do a lot of stuff with it. I generate immutable data types with a combination of live templates and class templates.

So my idea is to provide blueprints for event sourced aggregates and messages as PHPStorm templates. It's possible to share them so ppl can import the templates and customize them if needed. I'd say you get best of both worlds and PHPStorm is a de facto standard these days.

Thoughts?

wow thats great are you gona teach me?

from event-sourcing.

@MichaelVictor Regarding immutable data types you can read more about it in the Event Engine docs

from event-sourcing.

Superseded by #90

from event-sourcing.