[quwer]

Prosze o opinie - jestem w nowym projekcie i mamy mocny nacisk na DDD.
Na poziomie controlera i service stosujemy konwertery, ktore zamianiaja jeden obiekt na drugi
Wada tego rozwiazania jest to, ze konwertery nie sa testowane(dla obiektow, ktore maja wiecej pol jest to problematyczne), a dwa ze jest ich duzo i kazdy dodatkowy konwerter wymaga stworzenia nowego obiektu Dto.
Jaka moze alternatywa dla takiego rozwiazania?

public ResponseEntity findCarLocalized(
final UUID id, final String acceptLanguage) {
return ResponseEntity.ok(
readDtoConverter.convert(
carService.findByIdLocalized(id, LanguageCode.fromString(acceptLanguage))));
}

public CarReadDto findByIdLocalized(final UUID id, LanguageCode languageCode) {
return carToReadDtoConverter.convert(
this.stationRepository.findById(id).orElseThrow(() -> new CarNotFoundException(id)),
languageCode);
}

#programowanie #java

[alex-fortune]

@quwer: sam pomysł jest spoko, po prostu potrzebujecie czegoś co Wam to względnie to zautomatyzuje zamiast zebyscie musieli boilerplate sami pisać.

[quwer]

@alex-fortune: znasz jakies narzedzie do automatyzacji?

[Myzreal]

@quwer: Mam podobny problem jak piszę apki sobie prywatnie i próbuję się trzymać DDD. Przy każdym przejściu między warstwami (np z core aplikacji do warstwy http) muszę przemapowywać na (czasem identyczny) obiekt żeby nie leakować wewnętrznych obiektów na zewnątrz. Nie znam jeszcze dobrego rozwiązania na to więc taktyk

[Smevios]

@quwer: pokazałeś przykład Read Modelu, pytanie brzmi czy potrzebujesz ileś warstw żeby ograć Read Modele (a jeżeli tak, to co one wnoszą)? Może rozdzielnie stosu zapisu i odczytu, i zastosowanie różnych styli (styl pod potrzebę) rozwiązałoby problem? W ogólności, jeżeli pomiędzy warstwami nic się nie zmienia, to po co te warstwy?

[markaron]

@quwer: Poczytaj o CQRS. W skrócie w aplikacji masz dwa modele Read i Write. Model odczytowy (Read) to zwykłe DTO. Zwracasz je bezpośrednio z query handlera czy jakiegoś serwisu. Innymi słowy nie pobierasz encji domenowej którą potem mapujesz na DTO. Model zapisowy (Write) to zbiór encji domenowych najlepiej nie anemicznych, za pomocą których robisz inserty, update'y delete'y itp. Ogólnie realizujesz logikę biznesową. I wtedy robisz mapowwanie przychodzących DTO na model dziedziny

[alex-fortune]

@markaron: tu raczej chodzi o overhead boilerplate'u przy tworzeniu, a to co piszesz a propos walla to w ogole jest kwestia tego ze jest fanout writeów ( kwestia tego skad sa dane czytane a gdzie zapisywane ), co oczywiscie mozna zamknąć w CQRS ale nie o to OP pytal

[j.....6]

W ogólności, jeżeli pomiędzy warstwami nic się nie zmienia, to po co te warstwy?

@Smevios: jest ostatnio moda robienia CRUDów metodą DDD