Możemy uciec się do rozwiązań typu Datoms (Encja, Atrybut, Wartość, Timestamp) lub bardziej "semantycznego" Event Sorcingu.
Jednak są to rozwiązania specyficznych klas problemów (podróże w czasie, wektory uczące dla Sztucznych Sieci Neuronowych) lub problemów skali Googl/Twitter/Facebbok - mimo, że nie pracujemy w tych firmach, to lubimy się na nie powoływać w swych elaboratach architektonicznych:)
Natomiast w typowych systemach biznesowych wystarczy przyjęcie prostych i racjonalnych zasad doboru odpowiedniego młotka do odpowiedniej klasy problemu:
- Obiekty persystentne to Agregaty, których granice są wyznaczane wg dobrych praktyk DDD: np. modelowanie niezmienników oraz modelowanie jednostki zmiany biznesowej
- Do persystencji Agregatów używamy ORM, ponieważ dobrze zakreślone granice agregatów (w tym unikanie zbędnych połączeń) rozwiązują większość problemów
- Do wydajnego odczytu danych przekrojowych nie używamy ORM - nie służą do tego typu zadań
W razie problemów z wydajnością warto spróbować różnych form separacji z podejścia: Command-query Responsibility Segregation.
//==========================
Więcej w archiwalnym poście, natomiast rozwinięcie w najbliższym numerze programistamag.pl
6 komentarzy:
A jak widzisz w kontekście tego wpisu swój komentarz do tego posta http://mbartyzel.blogspot.com/2011/03/po-co-orm.html ?
Z CRUDEami jest prosta sytuacja, więc podtrzymuję.
Natomiast przy złożonych domenach problemy, o których pisałem - wynikające z LazyLoadingu i Operacji Kaskadowych można zniwelować/zredukować dzięki:
- CqRS - bo odczyt wartości to inna "bajka" operowanie na "miejscach" danych
- Dobrej definicji Agregatu - aby nie naciąć się na sytuację gdy opóźnione pobranie danych zwróci nam stan z innego momentu w czasie niz moment pobrania Agregatu
A co sądzisz o bazach dokumentowych jak MongoDB? Czy nie wydaje się bardziej naturalne dla zapisywaniu agregatów w formie dokumentu niż rozstrzelonego na dziesiątki tabel? Fowler obecnie zdaje się że proponuje to rozwiązanie jako bardzo rozsądne.
Osobiście nie mam tutaj doświadczenia produkcyjnego (z Mongo), ale jeżeli Agregat (jego granica) jest zaprojektowany zgodnie z DDD, to jak najbardziej ma to sens. A "rozstrzelanie na dziesiątki tabel" nie dość, że traci sens, to jeszcze sprawia pewne przykre problemy związane ze spójnością danych gdy używamy Lazy Lodingu. Napiszę o tym posta we wtorek/środę.
Natomiast jeżeli chodzi o wyszukiwanie, to i tak jeżeli chcemy osiągnąć wydajność, to read model jest zwykle nieodzowny.
Bazy NoSQL jak najbardziej nadają się do przechowywania agregatów: http://martinfowler.com/bliki/AggregateOrientedDatabase.html
<disclaimer>
Dewelopuję i sprzedaję produkt konkurencyjny dla Hibernate.
</disclaimer>
Zgadzam się z Tedem Newardem. ORM (w sensie Hibernate/TopLink/JPA) to Wietnam. Większość młodych chłopców nie wraca, a Ci co przeżyli cierpią na PTSD. Na głos popierają a po cichu, gdzie tylko się da używają Spring JDBC Template i tym podobnych.
Podoba mi się też metafora młotka. Można wtedy dobrać sobie najlepsze narzędzie do problemu. W systemach biznesowych relacyjna baza danych, nie oszukujmy się, to jednak "must be".
Nasze (programistów) dyskusje wciąż krążą wokół tematu "Chciałbym mieć coś pozbawionego wad Hibernate/JPA/TopLink, ale nie mam nic w zamian. Nie będę przecież pisać całego systemu w czystym SQL/JDBC." Wszystkie te burzliwe dyskusje rozpalają się i gasną regularnie bo wszyscy wciąż szukają alternatywy.
<reklama>
Ale, kto szuka ten znajduje :)
</reklama>
Prześlij komentarz