rayrutjes / domain-foundation Goto Github PK

Some command bus impl exist already (like https://github.com/SimpleBus).
I guess it would be better to keep things separated since event sourcing has nothing to do with the command pattern.

Currently, the abstract class that every aggregate root seems to extend avoids the usage of the constructor.
That's clearly a consequence of a technical, internal cause.

We must be able to easily replay all the events for a given stream, so that dematerialized views can be rebuilt.

I think we must have the option to make a projection listener replayable or not.

Find a way to enrich the events metadata with some useful correlation data like the command that was triggered.

Your documentation mentions running php-cs-fixer before submitting, however no information on what standards conformance is presence. Adding a .php_cs file indicating your preferred standards/requirements would be beneficial for contributors.

Hi all,

As you have noticed, as of today the library is very decoupled. We have introduced a lot of factories so that we respect the SRP, but this also allows us to mock everything when testing with phpspec.

@ciaranmcnulty, you argued on twitter that you never had to implement factories because of phpspec. I would really appreciate if you could take a look at my tests and maybe highlight where we went wrong.

The problem being that my classes are very behavioural, without much getters/setters.

I would like to deliberately couple some classes to others, and avoid the corresponding factories. I am for example thinking of the EventContainer.
In phpspec, there is no way to mock a class instantiated in a method, which makes it impossible to test subjects which have deliberate couplings.

Take the EventSourcedAggregateRoot as an example: https://github.com/RayRutjes/domain-foundation/blob/master/src/Domain/AggregateRoot/EventSourcedAggregateRoot.php

What if we simply wanted to instantiate an EventContainer directly without passing through a factory?
How would you write your tests in that case as you can no more expect calls on the EventContainer, and that is exactly what would need to be tested.

I have read the great articles proposed in this issue: phpspec/prophecy#184
Specially liked the 'don't mock everything' one. But I kind of feel this can not be applied to phpspec, because if you don't mock, you can't test, and everything breaks. By the way, I came to the conclusion that phpspec has a philosophy of "mock everything" so that you work in complete isolation.

Would also love to see some links pointing towards existing libs tackling this phpspec/factories problem.

I sincerely hope I am wrong about some of my assertions about phpspec, so that i can adapt my existing codebase/tests, and continue to use this awesome tool!

A domain model should be able to be defined only by its events and its identity.

All the rest (commited/uncommited/lastCommittedEventSequenceNumber/...) is persistence specific and therefore shouldn't be present in the AggregateRoot interface.

A snaphost is projection of an aggregate's state at a given time.

When we accumulate a lot of events for a given aggregate root, it might become costly to replay all the events to rebuild the state.

Snaphosts allows us to only replay the events that happened after the last snapshot.

This implies:

• Serialization/Deserialization strategy for AggregateRoots
• Snaphsot repository to store the snapshots

This will take the form of a nice website.
Probably built with something like couscous.

When persisting events of an aggregate root, we should ensure that no events have been persisted in the meantime.

If there is a conflict, we should throw a catchable exception, that can be handled by conflict resolvers.
If no conflict resolver were met during the exception bubbling, then the unit of work will rollback the whole transaction.