From 0cec47f95c76a142ccb2c3dcdf33f51e46b2835f Mon Sep 17 00:00:00 2001 From: Codeliner Date: Sun, 8 Jun 2014 20:19:10 +0200 Subject: [PATCH] Improve readability of sample --- README.md | 74 +++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 50 insertions(+), 24 deletions(-) diff --git a/README.md b/README.md index be500ff4..156c5bb4 100644 --- a/README.md +++ b/README.md @@ -47,17 +47,27 @@ You can install ProophEventStore via composer by adding `"prooph/event-store": " /** * This Quick Start uses the ProophEventStore together with ProophEventSourcing. - * ProophEventSourcing is an event-sourcing library which seamlessly integrates with ProophEventStore - * With the help of an EventStoreFeature shipped with ProophEventSourcing you can connect EventSourcedAggregateRoots - * with the EventStore @see configuration of the EventStore near the line 176 of this file. + * ProophEventSourcing is an event-sourcing library which seamlessly + * integrates with ProophEventStore. * - * Why is ProophEventSourcing not included in the library? Well, the answer is quite easy. Normally you do not want - * to couple your domain model with the infrastructure (which is definitely the right place for an EventStore) so - * the ProophEventStore does not force you to use specific event-sourcing interfaces or DomainEvent implementations. - * It is up to you if you use a library like ProophEventSourcing, Buttercup.Protects or provide your own - * implementation for your domain model. The only thing you need to do is, tell the EventStore which type of repository - * it should use. The EventStore defines it's own RepositoryInterface (Prooph\EventStore\Repository\RepositoryInterface) - * that you need to implement if you do not use ProophEventSourcing which ships with a ready to use repository implementation. + * With the help of an EventStoreFeature shipped with ProophEventSourcing + * you can connect EventSourcedAggregateRoots with the EventStore + * @see configuration of the EventStore near the line 176 of this file. + * + * Why is ProophEventSourcing not included in the library? + * + * Well, the answer is quite easy. Normally you do not want to couple + * your domain model with the infrastructure (which is definitely the + * right place for an EventStore) so the ProophEventStore does not force you + * to use specific event-sourcing interfaces or DomainEvent implementations. + * + * It is up to you if you use a library like ProophEventSourcing, + * Buttercup.Protects or provide your own implementation for your domain model. + * The only thing you need to do is, tell the EventStore which type of + * repository it should use. The EventStore defines it's own RepositoryInterface + * (Prooph\EventStore\Repository\RepositoryInterface) + * that you need to implement if you do not use ProophEventSourcing + * which ships with a ready to use repository implementation. * * * Assume, we have the following requirements in the composer.json @@ -78,7 +88,8 @@ namespace My\Model { use Prooph\EventSourcing\EventSourcedAggregateRoot; use Rhumsaa\Uuid\Uuid; - //EventSourcing means your AggregateRoots are not persisted directly but all DomainEvents which occurs during a transaction + //EventSourcing means your AggregateRoots are not persisted directly but all + //DomainEvents which occurs during a transaction //Your AggregateRoots become EventSourcedAggregateRoots class User extends EventSourcedAggregateRoot { @@ -101,7 +112,8 @@ namespace My\Model { //When the EventStore reconstructs an AggregateRoot it does not call the constructor again $id = Uuid::uuid4()->toString(); - //Validation must always be done before creating any events. Events should only contain valid information + //Validation must always be done before creating any events. + //Events should only contain valid information \Assert\that($name)->notEmpty()->string(); //We do not set id and name directly but apply a new UserCreated event @@ -121,10 +133,12 @@ namespace My\Model { */ public function changeName($newName) { - //Validation must always be done before creating any events. Events should only contain valid information + //Validation must always be done before creating any events. + //Events should only contain valid information \Assert\that($newName)->notEmpty()->string(); - //Also this time we do not set the new name but apply a UserNameChanged event with the new name + //Also this time we do not set the new name + //but apply a UserNameChanged event with the new name $this->apply(new UserNameChanged($this->id, array('username' => $newName))); } @@ -139,8 +153,10 @@ namespace My\Model { /** * EventHandler for the UserCreated event * - * By default the system assumes that the AggregateRoot has one event handler method per event - * and each event handler method is named like the event (without namespace) with the prefix "on" before the name + * By default the system assumes that the AggregateRoot + * has one event handler method per event + * and each event handler method is named like the event + * (without namespace) with the prefix "on" before the name * * @param UserCreated $event */ @@ -154,8 +170,10 @@ namespace My\Model { /** * EventHandler for the UserNameChanged event * - * By default the system assumes that the AggregateRoot has one event handler method per event - * and each event handler method is named like the event (without namespace) with the prefix "on" before the name + * By default the system assumes that the AggregateRoot + * has one event handler method per event + * and each event handler method is named like the event + * (without namespace) with the prefix "on" before the name * * @param UserNameChanged $event */ @@ -165,7 +183,9 @@ namespace My\Model { } } - //All DomainEvents have to be of type AggregateChangedEvent, these are specific events including a version + //All DomainEvents have to be of type AggregateChangedEvent + //(When using ProophEventSourcing), + //These are specific events including a version //and the related AggregateId class UserCreated extends AggregateChangedEvent { @@ -186,7 +206,9 @@ namespace My\Model { } } - //All DomainEvents have to be of type AggregateChangedEvent, these are specific events including a version + //All DomainEvents have to be of type AggregateChangedEvent + //(When using ProophEventSourcing), + //These are specific events including a version //and the related AggregateId class UserNameChanged extends AggregateChangedEvent { @@ -210,7 +232,8 @@ namespace { use Prooph\EventStore\Stream\AggregateType; $config = new Configuration(array( - //We set up a new EventStore with a Zf2EventStoreAdapter using a SQLite in memory db ... + //We set up a new EventStore with a Zf2EventStoreAdapter + //using a SQLite in memory db ... 'adapter' => array( 'Prooph\EventStore\Adapter\Zf2\Zf2EventStoreAdapter' => array( 'connection' => array( @@ -219,11 +242,13 @@ namespace { ) ) ), - //... and register the ProophEventSourcingFeature to connect the EventStore with our EventSourcedAggregateRoots + //... and register the ProophEventSourcingFeature + //to connect the EventStore with our EventSourcedAggregateRoots 'features' => array( 'ProophEventSourcingFeature' ), - //Features are loaded by a special ZF2 PluginManager which can be configured like all other ZF2 ServiceManagers + //Features are loaded by a special ZF2 PluginManager + //which can be configured like all other ZF2 ServiceManagers 'feature_manager' => array( 'invokables' => array( 'ProophEventSourcingFeature' => 'Prooph\EventSourcing\EventStoreFeature\ProophEventSourcingFeature' @@ -233,7 +258,8 @@ namespace { $eventStore = new EventStore($config); - //We use a feature of the Zf2EventStoreAdapter to automatically create an event stream table for our User AggregateRoot + //We use a feature of the Zf2EventStoreAdapter to automatically create an + //event stream table for our User AggregateRoot //Normally you use this functionality in a set up or migration script $eventStore->getAdapter()->createSchema(array('My\Model\User'));