Domain Driven Design, Aggregate und Lazy Loading

Hallo,

das hat jetzt nichts direkt mit Java zu tun, aber ich fand keine passendere Rubrik.

Ich bewege mich in einem Projekt in einer hexagonalen Architektur und DDD. Ich habe ein Aggregate (nennen wir es ChatChannel) und dies enthält eine Liste von Member. Diese Liste kann nun sehr groß werden (> 10.000 Datensätze).

Ich möchte so etwas wie JoinChannel direkt als Funktion innerhalb des ChatChannels realisieren, um dort die Businesslogik zu implementieren. Damit sind die Member eigentlich Teil des Aggregates ChatChannel.

Aktuell habe ich die Businesslogik in einen Applicationservice gekapselt und ChatChannel und Member sind eigene Rootentitäten. Schön finde ich das jedoch nicht.

Hat jemand damit Erfahrungen?

Gefunden habe ich folgendes: http://thinkbeforecoding.com/post/2009/03/04/How-not-to-inject-services-in-entities

Aber der Eintrag ist etwas älter und mehr konnte ich dazu nicht finden. Ist so ein Vorgehen valide?

Die Frage ist doch, ob „JoinChannel“ im Member, ChatChannel oder gleich in einem eigenen Service implementiert wird, kann ich nur schwer sagen von hier aus
Deswegen nur vage Ansaetze von mir :slight_smile:

Die Zugehoerigkeit von Member zu ChatChannel koennte man als eigene Entity modelieren, scheint ja doch „wichtig“ zu sein dieser Domaene.
Pagination von Posts wuerde vielleicht in ein Repository packen, speziell mit LazyLoad past das ganz gut IME.

Wie gesagt, alles recht grob aber so als Ansatz zur Diskussion

1 „Gefällt mir“

Ich möchte halt verhindern, die gesamte Businesslogik in Services auszulagern. DDD hat ja zum Ziel, dass die Businesslogik “nahe” am Fachmodell zu finden ist.

Auch nach OOP würde ich sagen, dass eine Join-Methode durchaus fachlich in ein Channel passt. Das würde auch alles funktionieren, wenn man nicht zu große Datenmengen behandelt.

Gefühlt finde ich es jedoch falsch, das Fachmodell an der eigentlichen Last zu designen, oder?