README.md in sandthorn-0.12.0 vs README.md in sandthorn-0.13.0

@@ -220,23 +220,60 @@
 In this exampel the `events` method will generate a method called `marked`, this method take *args as input that will result in the method argument on the event. It also take a block that will be executed before the event is commited and is used to groups the state changes to the event (but is only optional right now).
 
 ```ruby
 class Board
   include Sandthorn::AggregateRoot
-  
+
   events :marked
-  
+
   def mark player, pos_x, pos_y
     # change some state
     marked(player) do
       @pos_x = pos_x
       @pos_y = pos_y
     end
   end
 end
 ```
 
+### `Sandthorn::AggregateRoot::constructor_events`
+
+Before version 0.13.0 the only initial event on an aggregate were `new`. With the `constructor_events` its possible to be more specific on how an aggregate came to be.
+
+```ruby
+class Board
+  include Sandthorn::AggregateRoot
+
+  # creates a private class method `board_created`
+  contructor_events :board_created
+
+  def self.create name
+
+    board_created(name) do
+      @name = name
+    end
+  end
+end
+```
+
+### `Sandthorn::AggregateRoot::stateless_events`
+
+Calling `stateless_events` creates public class methods. The first argument is an `aggregate_id`. The resulting event is attached to the referenced aggregate. The rest of the arguments are optional and are stored in the method_args of the event.
+
+When creating a stateless event, the corresponding aggregate is never loaded. The event is appendend to the aggregate's event stream.
+
+```ruby
+class Board
+  include Sandthorn::AggregateRoot
+
+  stateless_events :player_went_to_toilet
+
+end
+
+Board.player_went_to_toilet "board_aggregate_id", player_id, time
+```
+
 ### `Sandthorn::AggregateRoot::default_attributes`
 
 Its possible to add a default_attributes method on an aggregate and set default values to new and already created aggregates.
 
 The `default_attributes` method will be run before initialize on Class.new and before the events when an aggregate is rebuilt. This will make is possible to add default attributes to an aggregate during its hole life cycle.
@@ -262,11 +299,11 @@
 end
 ```
 
 `commit` determines the state changes by monitoring the object's readable fields.
 
-Since version 0.10.0 of Sandthorn the concept `events` have been introduced to abstract away the usage of `commit`. Commit still works as before but we think that the `events` abstraction makes the aggregate more readable. 
+Since version 0.10.0 of Sandthorn the concept `events` have been introduced to abstract away the usage of `commit`. Commit still works as before but we think that the `events` abstraction makes the aggregate more readable.
 
 ### `Sandthorn::AggregateRoot.save`
 
 Once one or more commits have been applied to an aggregate it should be saved. This means all commited events will be persisted by the specific Sandthorn driver. `save` is called by the owning object.
 
@@ -326,10 +363,10 @@
 
 In this case, the resulting events from the commands `new` and `mark` will have the trace `{ip: :127.0.0.1}` attached to them.
 
 ## Bounded Context
 
-A bounded context is a system divider that split large systems into smaller parts. [Bounded Context by Martin Fowler](http://martinfowler.com/bliki/BoundedContext.html) 
+A bounded context is a system divider that split large systems into smaller parts. [Bounded Context by Martin Fowler](http://martinfowler.com/bliki/BoundedContext.html)
 
 A module can include `Sandthorn::BoundedContext` and all aggregates within the module can be retreived via the ::aggregate_types method on the module. A use case is to use it when Sandthorn is configured and setup all aggregates in a bounded context to a driver.
 
 ```ruby
 require 'sandthorn/bounded_context'