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.
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
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
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?