crud

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