Download the PHP package xprt64/dudulina without Composer

On this page you can find all versions of the php package xprt64/dudulina. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package dudulina

CQRS + Event Sourcing library for PHP 7+

MIT Licence Build Status Scrutinizer Code Quality Code Climate Code Coverage Build Status

This is a non-obtrusive CQRS + Event Sourcing library that helps building complex DDD web applications.

Minimum dependency on the library in the domain code

Only 3 interfaces need to be implemented

No inheritance! Your domain code remains clean and infrastructure/framework agnostic as should be.

Even if only a few interfaces need to be implemented, you could loose the coupling to the library even more. You could define and use your own domain interfaces and only that interfaces would inherit from the library interfaces. In this way, when you change the library, you change only those interfaces.

Minimum code duplication on the write side

On the write side, you only need to instantiate a command and send it to the CommandDispatcher;

Let's create a command.

Now, let's create a simple event:

Somewhere in the UI or Application layer:

That's it. No transaction management, no loading from the repository, nothing. The command arrives to the aggregate's command handler, as an argument, like this:

The read models receive the raised event to. They process the event after it is persisted. Take a look at a possible read model:

The Read-models can be updated in a separate process, in realtime-like (by tailing) or by polling the Event store or even using JavaScript. Read more here about how you can keep the Read-model up-to-date.

So, when a command is dispatched the following things happen:

If an exception is thrown by the command handler on the aggregate, no events are persisted and the exception reach the caller

Read the entire documentation here

The Event store

There is a MongoDB implementation of the Event store and a Restful HTTP API for this Event store if you want to build Read-models in any other languages than PHP.

A JavaScript connector is also available. Here you can find some examples of updating a Read-model in JavaScript.

The Queries

The library can dispatch queries also. The Askers ask questions and the Answerers answser them.

The Askers ask question to the \Dudulina\Query\Asker and the can receive the answer as return value or as callback on them (the method $this->whenAnsweredXYZ or the one marked with @QueryAsker).

The Answerers answer questions at the $this->whenAskedXXX or @QueryHandler marked methods. They can also answer a question when they know that the answer has changed and all the askers are notified, by calling \Dudulina\Query\Answerer::answer().

CQRS bindings

How does the library know what command handler to call when a command is dispatched? Or what read models to notify when a new event is published? The answer to all these questions is CQRS bindings.

Long story short, the tools analyze the domain code, detect the handlers and build a PHP file with all the bindings as classes. Then you use those classes to configure the CommandDispatcher. The create_bindings.php must be run every time the domain code changes.

Then you need to include the file create_bindings.php to your index.php usually after vendors/autoload.php.

Sample application

A Todo list sample application can be found at github.com/xprt64/todosample-cqrs-es.

Querying an Aggregate in DDD

Read more about how to query an Aggregate in order to test if a command will succeed or not, without actually executing it.

Questions?

Feel free to post to this group: https://groups.google.com/forum/#!forum/cqrs--event-sourcing-for-php.


All versions of dudulina with dependencies

PHP Build Version
Package Version
Requires php Version ^8.0
psr/container Version ^1.0
xprt64/types Version ^1.0
xprt64/iterator Version ^1.0
psr/log Version ^1.0
xprt64/code-analysis Version ^1.1.15
xprt64/selector Version ^0.0.3
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package xprt64/dudulina contains the following files

Loading the files please wait ....