W przykładzie wykorzystuje jedną bazę danych (w sensie serwera) i dwa schematy, ale równie dobrze mogłyby to być zarówno dwie bazy danych, jak i dwa zupełnie różne serwery. Jestem w trakcie przygotowywania przykładu z modelem raportowym zrobionym na innej bazie i mapowaniem w oparciu o Linq 2 SQL.

Jedyne pytanie jakie bym mial, to : W jaki sposob dane sa synchronizowane miedzy modelem dla zapytan i dla komend ?

Z tego co rozumiem, logicznie moglibysmy kozystac z dwuch baz danych lub majac dwa oddzielne schematy.

rafalb już sporo powiedział. Ja ze swojej strony podkreślę jeszcze kwestię optymalizacji. Miałem przypadek systemu, który zarządzał rachunkami. Rozdzielenie modeli do komend i do zapytań (mimo iż oba pracowały na wspólnej bazie danych) pozwoliło mi w modelu komend zrealizować różne typy rachunków przez dziedziczenie, podczas gdy w modelu zapytań mam enum “Typ”.

Dzięki możliwości wprowadzenia dziedziczenia mogłem znaczenie zmodyfikować zachowanie “rachunku technicznego” (w porównaniu do klienckiego). Usunąłem konieczność zapisu salda, co pozwoliło mi wykorzystywać jeden rachunek techniczny naraz w dowolnej ilości transakcji (jedyna operacja na nim wykonywana to “insert” do tabeli z listą operacji — brak blokady na poziomie SQL).

Nie muszę chyba mówić, jak bardzo zwiększyło to przepustowość mojego modelu:-)

Od strony “query” jedyną czynnością, która może się nie udać jest aktualizacja danych (w przypadku niezgodności schemy lub innego buga). W takim wypadku jestem skłonny zastosować tradycyjne metody i naprawić problem odpowiednim SQLem.

Warto zauważyć, że systemy CQRS oparte na event sourcing są o tyle lepsze, że tam istnieje możliwość odtworzenia “od początku świata” wszystkich zdarzeń aktualizujących bazę query. Dzięki temu po naprawie bug-a można po prostu “wygenerować” od początku bazę zamiast łatać SQLami.

Od strony “command” zapis danych i wysyłanie komunikatów jest w pełni transakcyjne — korzystam z DTC. W przypadku SQLServer-a jest to dosyć proste. Oracle podobno też nieźle sobie radzi. Problemy mogą być w wypadku innych, mniej “enterprajsowych” baz danych, takich jak MySQL. Zakładam jednak, że wtedy nie wykorzystywalibyśmy NSB, tylko jakieś lekkie rozwiązanie (AtomPub?)
Sposób, w jaki osiągnąłem transakcyjność opisałem tutaj: http://simon-says-architecture.com/2010/01/13/nhibernate-nservicebus-i-transakcje. Nie jestem z niego bardzo zadowolony. W kodzie NServiceBus wykorzystywana jest (i działa!) natywna integracja NHibernate i System.Transactions. Póki co nie wiem, skąd wynikają moje problemy z zastosowaniem tego mechanizmu:\

Osobiście widzę pewną dodatkową zaletę – bezpieczeństwo. Dzięki takiemu oddzieleniu teoretycznie możemy sobie pozwolić na udostępnienie większych możliwości zapytań dla warstw zewnętrznych bez obawy, że nasze główne źródło danych zostanie uszkodzone. Ale oczywiście ta koncepcja wymagałaby rozwinięcia i poeksperymentowania…