Written by Alexander Miertsch (@codeliner) - CEO prooph software GmbH - prooph core team - 2018-09-08
You may have read the official announcement by Sascha (@prolic) about the future of prooph components. Together with Sascha we decided to stop working on prooph/common, prooph/event-sourcing, prooph/service-bus and all related packages like the various message queue adapters.
Event Machine makes use of the packages so one may ask if Event Machine is effected by this announcement as well? The short answer is:
Yes it is effected but we continue to work on Event Machine.
If you want to know the reasoning behind these decisions and what we plan to do (prooph software GmbH team), this post provides you with answers.
I'd like to go into details about the prooph components decision first. I think it is important to understand the reasoning and it will give you a better idea of what you can expect from Event Machine in the future.
As the author of the very first prooph components back in 2014 I'm involved in core development since the first commit. prooph/common and prooph/event-sourcing always had the problem that one needs to extend message classes and aggregate roots from prooph. You can use custom messages and aggregate root implementations but this is not an easy task within the current design of the components. It's a big issue because prooph never wanted to be a framework. Independent components have a very high priority for the core team. Prooph is meant to be used in enterprise applications which should not be coupled to a framework.
With a completely new event store implementation in the pipeline we revisited the problem. And because more teams use prooph in production, we receive requests from the community to provide better ways for custom messages as well as project specific needs for message serialization and such things.
Now we could try to support all those concerns by adding more and more possibilities to tweak prooph, but this has a high price: complexity Even with the current design of prooph components one has a hard time to get started. A reason why Event Machine exists. If we would add more configuration options and whatnot, it would get worse.
Back in the days, I started working on prooph because CQRS and Event Sourcing is a fascinating approach and can inspire you to solve problems in a completely different way. It needs some time and practice to get it right. Hence, battle-tested open source components might help developers to learn it without making the same mistakes. This still holds true, but can be limited to a proper event store implementation (including at-least-once message delivery for projections). We believe that a good event sourcing tutorial together with blueprints for event sourced aggregates and their repositories and a rock-solid prooph/event-store available as open source is the better approach for the prooph community. New developers get a recipe to get started and can rely on a high quality event store implementation. If the provided event sourcing blueprint doesn't fit a use case it can easily be adopted because the team owns the event sourcing code as well as the repository implementation that talks to prooph/event-store.
Dropping development of prooph/service-bus has other reasons. The component is designed to run in a modular application - think of ZF2 MVC or Symfony bundles. Since 2014 things have changed. The Zend Framework team promotes usage of zend expressive. Symfony made it easier to develop bundle-less applications. That said, nowadays both major frameworks advocate smaller application size with less layers and less complexity.
Prooph components do the same with prooph/micro, which doesn't use prooph/service-bus. A software service bus introduces an additional layer. This is especially useful in a modularized monolithic application. If you don't use modules, you don't need a software bus or at least nothing with the complexity of prooph/service-bus. For our daily work we no longer need prooph/service-bus and that's true for Sascha (he is not working for prooph software), too.
Hence, we decided together that if one needs a software message bus they have a lot of similar choices today. We don't need to spend our time on maintaining yet another solution.
If I could buy time with money, I'd do it and all prooph components would have a "buy me a minute" donation button. But you cannot buy time (yet?), therefor we need to be very careful with it. Working on open source is a great experience especially within the prooph community. On the other hand it reduces available time a lot and always competes with family and friends time as well as payed work. Many big open source projects are baked by companies with even bigger budgets, but that's a different league. The prooph community is awesome. Join the improoph chat and you'll know what I mean. But we don't have core developers who get payed to maintain prooph. It's more or less all based on community work.
Not enough time, new software architecture approaches and the availability of other software message bus solutions are the reasons for dropping prooph/service-bus support. It's still a great package, so this decision is not an easy one.
Now let's look at Event Machine. prooph/event-sourcing and prooph/service-bus are both used under the hood. The good news is, that you don't interact with them directly so we can easily replace the packages. But what about the reasons? Don't they apply for Event Machine as well?
I'm going to answer for each:
Event Machine is a rapid application development framework. You either use it as-is or don't use it at all. That's a big difference compared to prooph components and also the reason why Event Machine is not part of the prooph components family but only maintained by the prooph software team (different vendor, different copyright). My company is interested in future development because we need it for our daily work.
Event Machine is a great way to explore the world of CQRS and Event Sourcing without learning all theory upfront and spending days on putting all the pieces together. It is also a great way to develop prototypes and smaller applications. If you practice Domain-Driven Design, you probably know the difference between core domain and supporting domain. You should also know that it is not a good idea to solve all software problems with high quality implementations but rather focus on the core domain and design the rest of the system in a way that it works and is maintainable without too much effort. Event Machine is best used in supporting domains. It can be used for prototypes of core domains but only if you design the core domain in a way that you can easily delete and replace parts of it.
Having said this, Event Machine doesn't have the same problem like prooph/event-sourcing. A service developed with Event Machine is coupled by design. You need to be aware of the coupling and decide upfront (or after prototype phase) if that is ok for the service or not.
It is not recommended to develop a monolith with Event Machine. The concept works really nice within clear service boundaries. Therefor, Event Machine doesn't need a complex message bus. prooph/service-bus was integrated because early versions of Event Machine were used as a workshop framework - a prooph components glue layer. Replacing the service-bus package with a simple message dispatcher implementation isn't problematic.
As I already said, we need Event Machine for our daily work so prooph software GmbH is interested in ongoing development. This is also true for the new prooph/event-store implementation which will become the heart of Event Machine 2.0.
I'm not aware of any PHP open source library/framework that provides similar mechanisms like Event Machine does. prooph/micro is based on the same idea of functional event sourced domain behaviour, but does not provide the same RAD mechanisms. In fact, prooph/micro is suitable for core domains (once stable), but requires more design decisions and work. I'll discuss this in detail in a future post.
Our plan was to finish documentation first and add some more tests before releasing Event Machine v1.0. Due to the prooph components announcement the plan changed. v1.0 will be released soon. Several projects already use Event Machine and a stable release will ensure that those projects don't run into trouble when we start refactoring of Event Machine. Work on documentation will be paused. In fact, the Event Machine tutorial is all you need to get started. API documentation will cover more details, but this has to wait.