Problem, z którym ciągle się spotykam, polega na tym, jak radzić sobie z obliczonymi wartościami opartymi na logice domeny, a jednocześnie skutecznie pracować z magazynem danych.
Przykład:
Zwracam listę Produktów z mojego repozytorium za pośrednictwem usługi. Ta lista jest ograniczona informacjami o paginacji z żądania DTO wysłanego przez klienta. Ponadto DTO określa parametr sortowania (wyliczenie przyjazne dla klienta).
W prostym scenariuszu wszystko działa świetnie: usługa wysyła wyrażenia stronicowania i sortowania do repozytorium, a repozytorium wysyła wydajne zapytanie do bazy danych.
Wszystko się jednak psuje, gdy muszę posortować wartości wygenerowane w pamięci z mojego modelu domeny. Na przykład klasa Product ma metodę IsExpired (), która zwraca wartość logiczną na podstawie logiki biznesowej. Teraz nie mogę sortować i stronicować na poziomie repozytorium - wszystko byłoby zrobione w pamięci (nieefektywne), a moja usługa musiałaby znać zawiłości, kiedy wydawać te parametry repo i kiedy przeprowadzać sortowanie / stronicowanie samo.
Jedynym wzorcem, który wydaje mi się sensowny, jest przechowywanie stanu encji w db (uczyń IsExpired () polem tylko do odczytu i zaktualizuj go za pomocą logiki domeny przed zapisaniem). Jeśli podzielę tę logikę na osobne repozytorium „czytaj model / dto” i „raportowanie”, sprawię, że mój model będzie bardziej anemiczny, niż bym tego chciał.
BTW, każdy przykład, jaki tam widziałem, dla takich obliczeń, naprawdę opiera się na przetwarzaniu w pamięci i glosowaniu z uwagi na fakt, że na dłuższą metę jest znacznie mniej wydajny. Może przedwcześnie optymalizuję, ale to po prostu nie pasuje do mnie.
Chciałbym usłyszeć, jak inni sobie z tym poradzili, ponieważ jestem pewien, że jest to powszechne w prawie projekcie z udziałem DDD.