Unify implementation effort

[benjamindulau]

Hi,

I'd like to get your attention about a sensible subject ;-)

There are actually several independent efforts for providing libraries implementing CQRS or some parts of DDD concepts. Among them, there are two I found very neat and very interesting:

• http://buttercup-php.github.io/protects/ - @mathiasverraes
• https://github.com/beberlei/litecqrs-php - @beberlei

I'm torn because I think something really interesting could come up by combining efforts and then push everything further. I'd would love to contribute to a common project. It would also prevent from having a bunch of libraries in the near future, which I think won't be positive for PHP.

What do you think ? Maybe you're already planning something.

[szjani]

What's the problem with predaddy? :)

[mathiasverraes]

Benjamins framework was, from what he told me, never intended as production code. Buttercup has a rather different philosophy. It's just interfaces that I extracted from production code, and documentation. I do have ideas with where I want to go with it, but it depends on my availability and my clients. Predaddy is afaik the only cqrs project in php aiming at being a production ready framework.

[mathiasverraes]

btw There are thousands of frameworks for php. Competition of ideas is, in my opinion, extremely positive for any ecosystem. :)

[benjamindulau]

@szjani I have nothing against predaddy but I think the library tries to do too much. I would tend to split it in several smaller projects, especially for the event store. Also, the code is already too much advanced with too much implementation choices having been taken.

What I like in benjamin's and mathias work is that they try to keep things simple and do not assume too much about how the whole thing should be implemented but rather try to somehow "educate" developers by advocating concepts over code.

But maybe I'm overlooking at it, and in the end, the Event Store is the only "heavy" stuff to implement. The rest being specific for each project.

BTW, did you already considerate a PHP client for the Greg Young's Event Store API ? https://github.com/eventstore/eventstore/wiki/Getting-Started-HTTP

@mathiasverraes I agree for the benefice about competition of ideas. What I meant is that in PHP, developers often do their own things in their corner. What I like in .NET is that they share common guidelines and they seem to evolve all at one about these subjects, and now, they got a really robust approach about DDD & CQRS.

Maybe I'm too much naive, but IMO PHP could really benefit from this. But to do so, only influential people and with legitimacy have the power to raise the general interest on these subjects! And I think that's what you, Benjamin and others are already doing, but each on your side, why don't you join forces ? :p

[szjani]

but rather try to somehow "educate" developers by advocating concepts over code

Yes, but as soon as you start using these theories in practice you will be faced with several problems. You can solve them in every project or you can use a library.

I would tend to split it in several smaller projects, especially for the event store

Doctrine-related (mainly Event Store) classes contain less, than 1000 lines of code which could be in a separated project of course, but I think it is not a big issue right now at least until more implementations are available.

A lot of interfaces have been introduced in order to be flexible and let users create their own implementations. If you have any proposals or ideas around predaddy, please contact me or open an issue. I would really appreciate it.

did you already considerate a PHP client for the Greg Young's Event Store API

Not yet, but thanks for the tip.

[beberlei]

The requirements of a cqrs library (with or without Event sourcing) are so specific that its really hard to develop a generic library that is usable for people out of the box. I would like to see a client library for Event Store, but every thing else is really about the implementation details and then becomes not more than 1000-2000 LOC in an application. To me that is very acceptable for something so central.

[mathiasverraes]

@benjamindulau
You assume I'm working alone, but nothing is farther from the truth :)
Buttercup is, even though I wrote it, heavily based on work that I did last year with @huizendveld and this year with @stivni and @Steerlin, along with what I learned from others in DDDBE and the wider community. All that code isn't open sourced ATM due to practical concerns, which is why I took one aspect and extracted interfaces for it.

[mathiasverraes]

s/@huizendveld/@marijn