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
