Encje biznesowe a porty z architektury heksagonalnej

Mam przykładową encje/obiekt

final class Game {

    private UUID uuid;
    private String name;
    private LocalDateTime startTime;
    private List<Bet> bets;
    //Dowolne inne pola związane z biznesem
    
}

i chciałbym mieć jakiś port (z architektury heksagonalnej) do zapisu/odczytu danych. Teraz zaczyna się pytanie: jakie typy powinien taki port przyjmować i zwracać?
Rozwiązania o których myślałem:

1. Każdy obiekt biznesowy ma metody toDTO, fromDTO oraz odpowiednie DTO, które przez port jest przekazywane do "zapisania". Wtedy sam obiekt biznesowy nie wystawia na świat informacji o swoim wnętrzu, a obiekt DTO jest dodatkową granicą pomiędzy warstwami.
2. Obiekt biznesowy jest tylko strukturą danych: gołe pola(mogą być wtedy public final), a wszystkie operacje wykonuje wyższa warstwa (przypadków użycia). Wtedy do portu jest przekazywany sam obiekt.

Czy może oba podejścia są błędne i jest jakieś inne, lepsze?

Jeśli port ma dostęp (może mieć referencje do) typu zdefiniowanego w warstwie biznesowej to dla czego by jej nie używać? Co rozumiesz przez obiekt biznesowy nie wystawia na świat informacji o swoim wnętrzu? Od tego jest enkapsulacja i prywatny dostęp. Mając publiczne gettery nie wystawiasz "wnętrza" typu a jedynie jego publiczny kontrakt.

zasadniczo zamiast getterów to już lepiej jest mieć pola publiczne, finalne. Efekt ten sam, a mniej kodu to pisania ;)

edit
W sumie jeszcze cos. Jeśli już traktować gettery jako interface klasy (ale imo to trochę samooszukiwanie się), to można potraktować gettry jako zbiór informacji, które chce się wydostać z obiektu na zewnątrz. W takim przypadku można je zebrać w jeden obiekt i wychodzi takie DTO

To czy masz gettery, czy finalne pola publiczne czy właściwości to kwestia konkretnego języka i podejścia. Gettery użyłem jako przykład, nie ma to większego znaczenia i to co napisałeś nijak ma się do Twojego pytania.

imo to trochę samooszukiwanie się

Dla czego?

W takim przypadku można je zebrać w jeden obiekt i wychodzi takie DTO

Można, a czasem trzeba. Pytanie tylko czy rozwiązuje to konkretny problem, czy jest to przerost formy nad treścią.

Punkt 1 wydaje się bez sensu.
Punkt 2 miał by sens w programowaniu funkcyjnym gdzie za Porty/Adaptery odpowiadają monady.

Wtedy sam obiekt biznesowy nie wystawia na świat informacji o swoim wnętrzu, a obiekt DTO jest dodatkową granicą pomiędzy warstwami.

Jeśli borykasz się z tego typu problemem to może lepszy będzie ACL?

@danek: IMO obiekt biznesowy to powinien być niemutowalny obiekt (nikt sie nie spodziewał że tak napisze, prawda? :D) z publicznymi polami final lub getterami. Zaletą getterów jest to że mozna wywoływać jako referencje do metod, ułatwia to operacje na streamach/bibliotekach funkcyjnych.
Obiekty domenowe powinny tez wykorzystywac value objecty (zamiast String isbn lepiej Isbn isbn) i same być walidowane(np. wymagane pola). Moim zdaniem dodatkowo porty i adaptery powinny wykorzystywac obiekty domonowe/value objecty w API jeśli to możliwe - np.

interface UserRepository {
  Option<User> findById(UserId userId);
}