Archives pour la catégorie CQRS

Recettes CQRS, pour bien cuisiner son architecture

Voici une vidéo de présentation du CQRS au Microsoft User Group de Lyon. C’est très instructif sur le chemin qui mène au CQRS avec le DDD et l’Event Sourcing. Elle aborde des détails rarement abordés dans ce genre de présentation.

Les questions en fin de présentation sont également intéressantes. Et vous qu’en avez-vous pensé ? Où en êtes vous avec le DDD ? Qu’est ce qui se passe pas bien ?

[Updated] DDD with Broadway and the Design Pattern State

Note : This article is the translate of this article. I use Google Translate for help me to write in english. Please, if you read wrong phrase send me the correct by one comment.

In a refactoring sprint, I found that my main aggregate class took much overweight.

I had exceeded 750 lines of code with, in many actions, a « switch » or a dozen « IF ». This did not please me very much because, if a change was required with this level, the amendment would be difficult.

Continuer la lecture de [Updated] DDD with Broadway and the Design Pattern State 

[MàJ] DDD avec Broadway et le Design pattern State

[English version]

Au cours d’un petit sprint de refactorisation, j’ai constaté que la classe de mon principal agrégat prenait beaucoup d’embonpoint.

J’avais dépassé les 750 lignes de code avec, dans beaucoup d’actions, soit un “switch » soit une petite dizaine de “IF”. Cela ne me plaisait pas beaucoup car, si une modification était demandée à ce niveau-là, la modification serait délicate.

Continuer la lecture de [MàJ] DDD avec Broadway et le Design pattern State 

[Updated] Symfony, Broadway and the replay event

Note : This article is the translate of this article. I use Google Translate for help me to write in english. Please, if you read wrong phrase send me the correct by one comment.

On of the main advantages of EventSourcing is the replay event for build a new view database or sync the an old view.

Do have you ever wondered how to go about not send emails on events issued by the aggregates ?

In my case, the dilemma is rather important because many things are based on events. If they are replayed, all treatments are rerun.

In my project, I use Broadway (by QandidateLabs) for implementing the CQRS/ES.

For use the default event bus, you must tag any services with broadway.domain.event_listener and extend this class Broadway\Processor\Processor.
All services will be injected into the event bus by a compiler pass. The latter takes 3 arguments: the event bus service identifier, the tag used for get all services to inject her, and the interface name that services must implement to be injected.

You can reuse the code to add a new event bus without write more code.

3 steps for separate into new bus all services necessary for refresh view.

1) Add a new event bus

2) Add new tag for all services to update the view. By exemple mon_bundle.domain.event_listener.
3) Run new compiler pass with new parameters

This is a SOLID code.

Your event listener must also be. One listener one responsibility.

Finally, during the retransmission of events, simply send them on the bus dedicated to replay events to perform the update only the view.
That’s done! You can retransmit all the events to update the view without having to change the configuration of the production application to prevent the resend of the emails.

Get the source code on github.

Now you can share your experiences in the comments.

[MàJ] Symfony, Broadway et le replay d’event

[English version]

L’un des principaux atouts qui reviennent souvent lorsque l’on parle de l’EventSourcing est la réémission des évènements afin de reconstruire la vue (par exemple). Cela peut être pour la construction d’une nouvelle base de vue ou le rafraichissement de la vue désynchronisée.

Ne vous est-il jamais arrivé de vous demander comment s’y prendre pour ne pas renvoyer les emails basés sur les évènements émis par les agrégats ?

Continuer la lecture de [MàJ] Symfony, Broadway et le replay d’event