Mongo część query

Cześć, czy stosująć Mongo i chcąc używać wzoraca CQRS mamy jakieś sprawdzone sposoby na część query ? Bo tu raczej nie ma joinów czy widoków jak w relacyjnej DB.

Chciałbym oddzielić obiekty domenowe z logiką od projekcji zwracanych na potrzeby klientów.

Chyba, że muszę ręcznie to wszystko pisać i joinować w kodzie ?

Z "definicji" masz 2 modele - do odczytu (zdenormalizowany!) i zapisu. Czyli możesz mieć 2 oddzielne kolekcje na Mongo. Pomyśl o tym w ten sposób, że być może przy odczycie kiedyś podmienisz Mongo na Elastica.

Ew. masz coś takiego: https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/ ale to się mija z celem.

@Charles_Ray:

Ok, ale do takiej architektury potrzebuję emitować eventy i aktualizować te kolekcje widokowe przy każdym zapisie prawda ? Czyli jakiś rabbit np.

Z SQL mógłbym po prostu tworzyć widoki w bazie albo jakimiś @ManyToOne to ogarnąc po stronie kodu.

1. Nie musisz emitować żadnych eventów - możesz po prostu aktualizujesz 2 dokumenty przy zapisie. Tracisz oczywiście gwarancję spójności danych. Oczywiście to się słabo skaluje w kodzie, więc jakiś pattern typu observer tutaj można zastosować i w ten sposób wpinać kolejne projekcje (modele do odczytu pod różne use casy). Ewolucją na poziomie architektury jest dostawienie kolejki i wejście w asynchroniczność. Spora cena, nie zawsze warto.
2. Nie. @ManyToOne jest joinem na poziomie SQL, a nie joinem client-side. Na start tworzenie widoków (a potem ich materializowanie) wydaje mi się dobrym pomysłem.

Polecam:

@Charles_Ray:

A jeśli mam Mongo i nie mam transakcji i wywali mi się zapis tego modelu widokowego to wjeżdża spora niespójność. Jak to się potem naprawia ? Jakoś za pomocą tego obserwatora, który muszę zaimplementować ?

Tak jak @Charles_Ray wspomniał, możesz po prostu zapisywać zdenormalizowany model na potrzeby widoku. Wtedy przechowujesz to jako jeden duży dokument, bez konieczność wyciągania dodatkowych dokumentów. Tak naprawdę nie ma tutaj znaczenia czy mowa o MongoDB czy jakiejkolwiek innej bazie. Poza tym jeśli chcesz zapisywać model command i query jednocześnie, z zachowaniem transakcyjności to warto rozejrzeć się za bazą która to w pełni wspiera jeśli masz możliwość. Uważaj na transakcje w MongoDB.

@Aventus:
Ok, odpowiada mi to z zapisywaniem modelu query od razu, aby nie wprowadzać asynchroniczności.

Zastanawiam się tylko jak ogarnąć case kiedy walnie mi zapis modelu query po tym jak zapis command się powiódł.

A musisz korzystać z MongoDB? Bo tak jak mówiłem brzmi to jakbyś potrzebował transakcyjności, a wtedy najlepiej użyć technologii która to ma (i działa). W przeciwnym razie będziesz musiał sam spróbować jakoś ogarnąć taką "transakcję", ale w tej kwestii nic nie jestem w stanie doradzić.

Jeśli piszesz coś od zera i nie masz jakichś ograniczeń to zastanów się może nad inną technologią. Od siebie mogę polecić RavenDB.

No właśnie ! :)

I to jest case tego tematu. Czy da się pożenić Mongo i CQRS w jakiś przyjazny sposób.

Bo SQLem to nie sztuka no.

Z tego co widzę to teoretycznie do tego masz multi-document transactions w MongoDB, ale polecam przeczytać podlinkowany wcześniej artykuł.