Leniwe referencje w domenie

Cześć,

istnieje prosta aplikacja obsługująca restauracje:

data class Dish(val name: String)
data class Customer(val name: String)

Dania oraz klientów trzymam w dwóch kolekcjach Mongo.
Czasami klient przychodzi do restauracji i prosi o swoje ulubione danie. Obsługa restauracji ma słabą pamięć, więc muszą zapisywać sobie ulubione dania klientów. Pierwszy pomysł to dodanie klientowi listy dań:

data class Customer(val name: String, val favorites: List<Dish>)

To jest fajne, bo mając klienta od razu mogę się dowiedzieć jakie są jego ulubione dania. Za każdym razem wyszukując klienta muszę dodatkowo wyszukać dania, żeby zbudować taki obiekt. Problem pojawia się gdy klient wcale nie poprosi o swoje ulubione danie, nie chciałbym wtedy pobierać sobie dań.
Drugi pomysł więc to przekazanie zbudowanie obiektu z jakimiś identyfikatorami wskazujacymi na dania. W takim wypadku mogę sobie je pobrać wtedy kiedy potrzebuję, ale nie korzysta się już z tego tak wygodnie.

data class Customer(val name: String, val favorites: List<DishId>)

Trzeci pomysł dosyć hardcorowy to opakowanie listy ulubionych w jakiś obiekt, który będzie działał leniwie - np. przy pierwszym zapytaniu pobierze sobie dania, a potem będzie je zwracał z pamięci.

data class Customer(val name: String, val favorites: LazyDishes)

Jaka jest dobra praktyka? Problem pojawił się gdy zacząłem od napisania samej domeny, a potem okazało się, że żeby zbudować "pełny" obiekt muszę za każdym razem pobierać dane z trzech źródeł. Jestem otwarty na artykuły/prezentacje dotykające tej tematyki :)

Jako że nie lubię ukrytych zależności (a LazyDishes jest przykładem ukrywania zależności), poszedłbym w stronę dwóch osobnych obiektów:

data class Customer(val name: String)
data class CustomerWithFavorites(val name: String, val favorites: List<DishId>)

Dzięki temu każda metoda przyjmująca Customer musi z góry określić który rodzaj obiektu ją interesuje, a i samo oprogramowanie tego jest proste :-)

W miarę rozwoju domeny CustomerWithFavorites zyskałoby pewnie jakąś ciekawszą nazwę, lecz przy obecnych wiadomych - imo wystarczy.

Hmm wyglada trochę jak klasyczne pomylenie modelu z widokiem. Nie znam całości, ale te ulubione wyglada jak niezależny ficzur od samego customera. Nie powinieneś za każdym razem dociągać danych, które może się przydadzą, a może nie, a ponadto są pobierane tylko na potrzeby prezentacji.

Do rozwiązań. Dlaczego nie możesz dociągnąć „ulubionych” z innej kolekcji, dopiero kiedy będą potrzebne? Ewentualnie stwórz sobie klase/widok CustomerWithFavorites, jeśli musisz to od razu prezentować na guju.