cqrs

Jak powinna wyglądać prosta CRUDowa aplikacja

Posted on Updated on

Często gdy omawiane są dobre podejścia typu DDD (czasem z Event Sourcingiem) oraz architektura heksagonalna to wspomina się “ale gdy jest prosty kawałek CRUDowy to zrób to CRUDowo”. Osobny kontekst osobna subdomena.

Tylko co to znaczy w tym przypadku sławne “encje na twarz i pchasz”? Nie miałem takiej potrzeby więc trochę posiłkuję się rozmowami z 125. Spotkanie WG.NET – Unconference i doświadczeniem.

CQRSa bym zdecodowanie dodał. Rozdzielenie Commandów od Queries ma bardzo dużo zalet nawet gdy baza jest prosta. CQRS sam w sobie nie mówi nic o tym jak ma wyglądać baza, czy mają być encje, agregaty w modelu DDD, czy może jeszcze Event Sourcing.

Więc:
Query pobiera sobie dane/widok skomponowany z kilku tabel.
Command robi Inserty/Updaty w bazie (w najprostszym przypadku nawet przenosząc klasy bazodanowe na FE, a może tylko DTO które jest 1 do 1 z modelem bazy).

Bez skomplikowanych Agregatów, bez przekombinowanego Event Sourcingu.

PS, jeszcze nie oglądałem w całości, ale Kamil którą tą rozmowę zainicjował wrzucił swoje repozytorium warte uwagi: https://github.com/kgrzybek/sample-dotnet-core-cqrs-api

Advertisements

Implementowanie CQRS

Posted on Updated on

http://weblogs.asp.net/shijuvarghese/cqrs-commands-command-handlers-and-command-dispatcher
– jak w praktyce zrobic prosty Dispatcher, Command, CommandHanler.
– jedynie powienienem nazwać CommandDispatcher zamiast CommandBus.

http://stackoverflow.com/questions/8184490/confusion-about-message-bus-command-dispatcher-patterns

– slajdy z prezentacji, które wiele mi dały, akurat też było w kontekście Ninject’a

nice AOP around CommandHandler
nice AOP around CommandHandler

– i już wiem gdzie dać logowanie błędów.

z prezentacji: https://www.youtube.com/watch?v=itQOsr9pmsg