Architektura hexagonalna (porty/adaptery) - logika

Czesc.

Z definicji, porty/adaptery sa abstrakcja do infrastruktury ( bazy danych, resty etc. ). Mam watpliwosci co jest logika biznesowa a co nie. Zalozmy, ze potrzebujemy w aplikacji informacji o aktywnych produktach danego uzytkownika. My jestesmy zainteresowani tylko aktywnymi produktami, czyli takimi ktore np. maja okreslany status czy maja jakas konkretna flage.

I tu pytanie, czy repozytorium powinno zawierac logike ktora filtruje nam te produkty ktorymi jestesmy zainteresowani (np. getActiveProducts()), czy w service/logice biznesowej powinnismy sobie to filtrowac a repozytorium zwraca nam caly zbior produktow. W tym pierwszym wypadku, repozytorium wie co to sa "aktywne produkty" natomiast w tym drugim, jest to zawarte w serwisie.

Definicja repozytorium to część domeny, więc jak najbardziej może istnieć metoda getActiveProducts w interfejsie ProductRepository (w domenie), a potem w infrastrukturze robisz implementacje np. PostgreSQLProductRepository i tam w tej metodzie umieszczasz zapytanie które pobiera tylko aktywne produkty.

Gdyby domena miała decydować o wszystkim i dostawać wszystkie produkty z bazy danych to wszystkie systemy oparte o hex byłyby bardzo nieoptymalne.

Repozytorium niczego "nie wie", ono jedynie dodaje jakiś warunek do wyszukiwania. To, jakie aktywne produkty mają znaczenie biznesowe nadal siedzi wyżej.
Ze względów wydajnościowych filtrowanie zawsze powinno odbywać się jak najniżej,

Na poziomie domeny wskaż „co ma być zrobione” (przekaż do metody repozytorium własny obiekt np. PersonCriteria, ProductQuery, ItemFilter), a adapter niech wie „jak to zrobić”.