Sind Entitäten "Infrastruktur" ? / Eintäten allgemein

[Boas Enkler]

Hallo


Mir stellen sich momentan einige Fragen zu Entitäten und wie diese
behandelt werdne sollen.

Als erstes sehe ich momentan immer weider 2 Varianten wie Entitäten
eingesetzt werden.
Woraus sich aber u.U. wieder folgen in deren Verwendung bzw.
sichtweise ergeben.

Also:
Entweder werden Entitäten als "Kontrakt zugehörig" gesehen, was zur
Folge hat, dass man diese auch in den Conract-Assemblies definiert

oder

Es gibt "Entitäten-Bibliotheken" welche Entitäten beinhalten und die
Kontrakte referenzieren die Entitäten.

Letztere Ansicht folgt imo daraus, dass man Entitäten als
"Infrastruktur" sieht. Diese infrastruktur steht in einem anderen
Zusammenahng als die Komponenten an sich.

Damit zusammenhängend ist auch die Frage ob Entitäten Logik beinhalten
dürfen, wenn ja kommt nur die "Entity in Contract"- Variante in Frage
damit die Entität an ihrem Kontrakt funktionalität auslösen kann.

Hat die Entität keine Logik (Inform von Aufrufen von Methoden des
Kontraktes mit der sie in Verbindung steht) so kommen zunächst einmal
imo beide Varianten in Frage.

Ich denke eine Entität sollte keine Strategie anbieten sondern sie
sollte viel mehr"sein" . Was mit ihr getan wird sollte ihr im seine
der Entkopplung egal sein.

Direkt damit zusammenhängend ist dann auch die Frage ob Entitäten ein
Interace haben sollten.
Das wäre aber so wie ich das sehe nur dann notwendig, wenn sie auch
eine Logik beinhalten.

Im weiteren Sinne stellt sich mir auch häufig die Frage, ob eine
Validierung auf Entitäten Basis stattfinden sollte. Weil dies wieder
ein Logik (Welche es im Zweifelsfall zu mocken gilt) darstellt.

Zusammenfassend denke ich dass Entitäten keine Logik (somit auch keine
Validierung) beinhalten sollten, dadurch werden auch keine Interfaces
benötigt und die Entitäten sind von den Komponenten entkoppelt.

Allerdings habe ich aber bisher die Entitäten in den Kontrakten
gepflegt, was ich nach dieser Überlegung inkonsequent finde. Weil
eigentlcih müssten die Entitäten ausser halb der Kontrakte existieren
und die Kontrakte einfach nur die Entitäten referenzieren die sich
benötigen.
Allerdings bin ich mir hier momentan nicht sicher.

Deswegen meine Frage : Wie seht ihr diese Punkte und wie handelt ihr
Entitäten?

[Sebastian Jancke]

Das sind sehr viele, sehr verschiedene Fragen. Ich fang einfach mal mit einigen an ;-)

Ich gehe mal davon aus, das für dich Entität = für mich Domain Object ist (und nicht Entity aus Evans).

Zunächst mal klingt für mich Entitäten-Bibliothek sehr nach "kanonisches Datenmodell". Davon bin ich kein Freund - und stehe mit der Kritik daran nicht alleine da. Das funktioniert einfach nicht, weil es für große Domänen nicht gut skaliert. Also lieber versuchen, mehrere Bounded Contexts zu schaffen und diese möglichst kompakt zu halten.

Sollen Entitäten Logik enthalten? Die Frage ist doch wohl eher: wie komplex ist deine Domäne? Und kannst du es verantworten mit Transaction Scripts zu arbeiten, ohne langfristig Handhabbarkeit, etc zu verlieren? Fowler diskutiert dies ausführlich in PoEAA. Wenn Transaction Scripts für dich passen, dann sollte nur gemeinsam genutzte Logik in den Entitäten liegen. Ähnlich wie im Boundary - Controller - Entity Ansatz. Wenn deine Domäne komplexer wird (und das werden eigentlich die meisten Non-Toy-Projekte, > 6 Monate) solltest du vielleicht über das Domain Model Pattern aus Fowler, PoEAA nachdenken.

Was ich zur Zeit noch nciht verstehe, ist der Zusammenhang bei dir zwischen Kontrakten und Entitäten. Mir scheint, du nutzt Entitäten zur Kommunikation zwischen verschiedenen Komponenten. Dies würde ich grundsätzlich nicht mit Domain Objects tun. Hier kommen dann alle möglichen Komponenten/Service/SOA Patterns ins Spiel Damit erübrigt sich für mich der Rest - hoffentlich ;-)

-Sebastian

[Boas Enkler]

Hallo Sebastian

Danke Antwort bringt mich aufjedenfall schonmal ein stückweiter.

Mit dem Domain Model Pattern habe ich mich noch nicht ausführlich
beschäftigt, werde ich jetzt aber tun, vielleicht erledigen sich dann
in der Tag einige Fragen :)
Generell dreht sich bei mir viel um die Frage, wozu sollen Entitäten
überhaupt logik haben?

Selbst eine Validierung kann kontext abhängig sein und sollte dass
dann nicht von einer eigenen Komponente abgebildet werden?

[Stefan Lieser]

> Generell dreht sich bei mir viel um die Frage, wozu sollen Entitäten
> überhaupt logik haben?

Was sonst macht eine Entität aus? Wenn es um reine Datenhaltung in
einem "Objekt" (eher Record) geht würde ich das als Data Transfer
Object (DTO) bezeichnen, nicht als Entität.

> Selbst eine Validierung kann kontext abhängig sein und sollte dass
> dann nicht von einer eigenen Komponente abgebildet werden?

Validierung liegt oft außerhalb der Entitäten. Mindestens dann, wenn
für die Validierung andere Entitäten oder Services (z.B. um eine PLZ
zu prüfen) benötigt werden.

Viele Grüße
Stefan

[Boas Enkler]

>Was sonst macht eine Entität aus?

Genau diese Frage beschäftigt mich in diesem Zusammenhang auch.
Ich denke eine Entität definiert sich durch ihren Zustand, welche
natürlich auch durch die Validität der Informationen definiert wird.

Es gibt sicher Zustände die eine Entität prüfen kann. Soetwas wie eine
Termin Entität stellt sicher, dass ihr Ende nach dem Anfang liegt.

Aber ob es z.bsp. gültig ist, dass ein Termin in der Vergangenheit
liegt, wäre z.bsp. Context abhängig. Oder ob die Anzahl der Teilnehmer
> 1 ist...
Eine Logik dieser Art kann meiner Meinung auch je nach Teilbereiche
einer Domäne Variieren und dennoch wäre es für mich die gleiche
Entität.

Deswegen kann die Gültigkeit eienr Entität in zwei Bereichen andere
Bedeutung haben oder ?
Daraus würde folgen dass eine Entität ihren Kontext kennen muss.

Oder handelt es sich dann um eine neue Entität ?
Oder sollte man einfach die Validierungsarten differenzieren in welche
die Entitäten und welche die Context bezogen sind ?

[Markus Zywitza]

Hallo Boas

 

für mich ist eine Fachklasse (Entität, Business Object, Domain Object) immer nur kontextbezogen existent, wodurch sind die Frage nach der Validität im Prinzip nicht mehr stellt.

 

In DDD gibt es das Pattern Bounded Contexts, das genau hierauf passt: Ein Modell darf immer nur in einem Fachkontext verwendet werden, sonst kann es zu ernsthaften Problemen kommen. Eric Evans Beispiel ist meines Wissens nach eine Kundenentität, die sowohl vom Marketing als auch von der Rechnungsstellung genutzt wird. Da wird klar, warum es zu Problemen kommt.

 

Für mich gilt ganz klar: wenn ich eine Klasse in verschiedenen Kontexten benutze, brauche ich für jeden Kontext eine auf diesen zugeschnittene Klasse.

 

Diese Klasse kann dann Logik enthalten oder auch nicht. Je nach Komplexität der Anwendung verwende ich entweder Fachmodelle (Domain-Model-Pattern, siehe auch DDD) mit interner Logik oder das TransactionScript-Pattern (Fowler), bei dem die Fachlogik in Prozessklassen gekapselt ist.

 

Letzteres macht vor allem Sinn, wenn die Fachlogik auf mehr oder weniger linearen Prozessen basiert, da dadurch besser abgebildet werden können, als wenn die Prozesse auf die verschiedenen Fachklassen verteilt sind.

 

-Markus 

[Boas Enkler]

Hallo
Mir ist aufgefallen, dass ich 2 Themen vermische
1. Validierung
2. Strukturelle Organisation

Also versuche ich mal diese 2 Punkte zu trennen, damit man leichter
diskutieren kann 

1. Validierung
leider sehe ich hier generell ein Problem und ich komme immer mehr
zudem Schluss, dass es damit zusammenhängt, dass es verschiedene Arten
von Validierung gibt.
Nehmen wir z. Bsp. eine Termin-Entität
Eine Validierung könnte sein Start < Ende.
Soweit ist alles ok.
Dass diese Validierung in der Entität statt findet, ist sicher
vorteilhaft, da es das Handling vereinfach.
Das Problem fängt aber z.bsp. bei dem Thema "Terminkollision" an.
Es gibt Bereiche bei denen Kollisionen egal sind => Keine Validierung
aber in anderen Bereiche in der gleichen Domäne (vielleicht einfach
nur ein anderer Benutzer oder andere Termin-Art) bedeutet eine
Kollision ein ungültiger Zustand. Ich denke hierfür sollte man keine
eigene Entität erstellen.
Wenn nun die Entität die Validierung übernimmt, kann es sein dass
diese ValidierungsPrüfung nicht in der gleichen Komponente liegt wie
die Termine-Entität selbst.

So könnten Termine Teil einer AppointmentManagement Komponente sein,
während die Kollisionsprüfung vielleicht auch auf Aufgaben mit einem
Zeitraum/ Sperr und Urlaubszeiten berücksichtigt.
Wenn nun die Entität selbst prüft, so bekommt ihr Kontrakt
Abhängigkeiten zu anderen Kontrakten weil sie ja z.bps.
ISperrzeiten.CheckConflicts(...) triggern muss.
Diese Bindung sorgt dafür dass Kontrakte in einer bestimmten
Reihenfolge erstellt werden muss und ein wesentlicher Vorteil der
Entkopplung durch DI &Co verloren.
Bei Komplexeren oder dynamischeren Anwendungen scheint mit das
TransactionScript Pattern nicht ausreichend.
DDD bringt dann aber die von dir genannten Probleme.

Deswegen ist es immer mehr mein Gedanke bei Validierungen zu
unterscheiden.
In Entitäten- und Context- (nicht Domain) bezogene Validierung.
Context bezogene Validierung würde demnach nur von den Komponenten
selbst durchgeführt werden.
Die Entitäten würden dann strukturelle und grundlegende Prüfungen
durchführen.

2.Strukturelle Organisation
Das Bounded Contextes Prinzip scheint hier nicht wirklich zu helfen.
So wie ich es verstehe geht es hier um ein Mapping zwischen
verschiedenen Entitäten da sich in verschiedenen DomainSpezifischen
Bereichen eine andere Bedeutung haben.
Die Idee hintendran finde ich sehr wichtig aber es kann ja auch sein,
dass eine Entität innerhalb des gleichen Bereichs von 2 Komponenten
Benötigt wird.
Mal angenommen man hat einen Anwendung welche SourceCodes verwaltet.
So kann es folgendes Szenario geben:
Eine SourceCode Entität bei einem SourceCodeAdapter, welcher
SourceCodes schreiben und lesen kann.
Eine Komponente welche sich um Versionierung kümmert und mit einer
VersionedItem Entität. Diese VersionedItem Entität beinhaltet nun
SourceCode.
Ich fände es nur logisch und auch für denjenigen der die Versionierung
verwendet , dass er hier als SubObjekt eine SourceCode Entität hätte.
Allerdings fände ich einen Verweis zwischen den Kontrakten des
CodeAdapter und Versionierungskomponente unnötig kompliziert, oder?
In so einem Scenario stellt sich mir die Frage ob es nicht besser wäre
ein Entitäten Assembly für die „SubDomaine“ „SourceCodeManagement“ zu
erstellen um unnötige Referenzen zu vermeiden.
Oder bin ich da auf dem Holzweg?

Was denkt ihr zu dazu?

[Sebastian Jancke]

Mir scheinen bei dir einige Dinge "durcheinander" zu gehen.

Wenn nun die Entität selbst prüft, so bekommt ihr Kontrakt
Abhängigkeiten zu anderen Kontrakten weil sie ja z.bps.
ISperrzeiten.CheckConflicts(..

.) triggern muss.

Mir ist immer noch unklar, welche Beziehung das Konzept "Entität" zum Konzept "Kontrakt" hat. Ein Kontrakt ist vor allem für Komponenten wichtig. Eine Entität kann aber immer nur der private Teil einer Komponente sein.
 

Diese Bindung sorgt dafür dass Kontrakte in einer bestimmten
Reihenfolge erstellt werden muss und ein wesentlicher Vorteil  der
Entkopplung durch DI &Co verloren.

Reihenfolge und Entkopplung sind ganz unterschiedliche Dinge. Bei jedem Abhängigkeits-Management gibt es eine Form von Reihenfolge, inder Abhängigkeiten aufgelöst werden müssen. Dies liegt in der Natur der Sache.

Bei Komplexeren oder dynamischeren Anwendungen scheint mit das
TransactionScript Pattern nicht ausreichend.

Ja. Und "komplex" sind Dinge nach meiner Erfahrung sehr schnell.
 

DDD bringt dann aber die von dir genannten Probleme.

 Welche Probleme meinst du?

dass eine Entität innerhalb des gleichen Bereichs von 2 Komponenten
Benötigt wird.

Ich würde eigenlich niemals einen Bounded Context in mehr als eine Komponente teilen. Das macht für mich wenig Sinn. Bounded Context setzt vor allem Grenzen, auch innerhalb der Domäne. Und diese Grenzen lassen sich zB durch Konrakte und Komponenten abbilden. Dies hat seine ganz eigenen Probleme und sollte wohl hier vorerst ausgeklammert werden.

Mal angenommen man hat einen Anwendung welche SourceCodes verwaltet.

Was genau ist dann deine Domäne bzw der Teil den du modellierst? Das was ich mir darunter vorstelle hat kaum eine Trennung zwischen Version und Datei. Vorallem aber sieht mir deine beschriebene Modellierung nach Datenmodellierung aus und nicht nach dem Verhalten (OO, Domänen Modelle mit OO, ...). Wo sind hier also die Gegenstände und ihr Verhalten in deiner Domäne? Wo brauchst du Bounded Contexts? Was sind dann die Dienste, die du davon nach außen einem Konsumenten bereitstellen musst? Dann erst weißt du wo deine Komponenten sich ausbilden. Da Entitäten private Angelegenheit dieser sind, kannst du die "Entitäten-Assembly" auch gleich über Board werfen. Zumal Komponente nicht automatisch = Assembly sein muss.

Ich hoffe ich konnte dir helfen,
Sebastian

[Markus Zywitza]

Hallo

ich gehe einfach von oben nach unten durch:

Am 26. Juni 2009 09:28 schrieb Boas Enkler <Admin_...@web.de>:

Nehmen wir z. Bsp. eine Termin-Entität
Eine Validierung könnte sein Start < Ende.
Soweit ist alles ok.
Dass diese Validierung in der Entität statt findet, ist sicher
vorteilhaft, da es das Handling vereinfach.
Das Problem fängt aber z.bsp. bei dem Thema "Terminkollision" an.
Es gibt Bereiche bei denen Kollisionen egal sind => Keine Validierung
aber in anderen Bereiche in der gleichen Domäne (vielleicht einfach
nur ein anderer Benutzer oder andere Termin-Art) bedeutet eine
Kollision ein ungültiger Zustand. Ich denke hierfür sollte man keine
eigene Entität erstellen.

Aus was besteht denn ein Termin? Wenn es sich nur um eine Zeitspanne handelt, ist es ein Value Object, dann übernimmt die enthaltende Entity die Validierung. Wenn es sich wirklich um eine Entity handelt, dann muss dieser Termin auch seine Teilnehmen, Ressourcen und andere Feinheiten modellieren. Dann kann der Termin aber auch anhand dieser Informationen validieren, d.h. unter anderem Sperrzeiten der Teilnehmer und Verfügbarkeiten der Ressourcen abfragen. Diese Abfragen sollte der Termin referenzierten Objekten durchfahren lassen, um die Kapselung zu gewährleisten.

Bei Komplexeren oder dynamischeren Anwendungen scheint mit das
TransactionScript Pattern nicht ausreichend.

Hatte ich ja gesagt, aber bei vielen Anwendungen ist es eben ausreichend, lineare Fachprozesse abzubilden.

DDD bringt dann aber die von dir genannten Probleme.

Man kann bei DDD lineare Fachprozesse auch gut als Domänenklassen abbilden. Dann wird das TransactionScript quasi zur Entity und lagert Teilfunktionalitäten an die referenzierten Enitities aus. Hier gibt es nicht nur schwarz und weiss.

 

2.Strukturelle Organisation
Das Bounded Contextes Prinzip scheint hier nicht wirklich zu helfen.
So wie ich es verstehe geht es hier um ein Mapping zwischen
verschiedenen Entitäten da sich in verschiedenen DomainSpezifischen
Bereichen eine andere Bedeutung haben.
Die Idee hintendran finde ich sehr wichtig aber es kann ja auch sein,
dass eine Entität innerhalb des gleichen Bereichs von 2 Komponenten
Benötigt wird.

Wenn diese Komponenten verschiedene Kontexte haben, kann man allerdings nicht ausschließen, dass ihre Verwendung der Klasse auseinanderdriftet. Dann kann es genau die beschriebenen Probleme geben. 

Mal angenommen man hat einen Anwendung welche SourceCodes verwaltet.
So kann es folgendes  Szenario geben:
Eine  SourceCode Entität  bei einem SourceCodeAdapter, welcher
SourceCodes schreiben und lesen kann.
Eine Komponente welche sich um Versionierung kümmert und mit einer
VersionedItem Entität. Diese VersionedItem  Entität beinhaltet nun
SourceCode.
Ich fände es nur logisch und auch für denjenigen der die Versionierung
verwendet , dass er hier als SubObjekt eine SourceCode Entität hätte.
Allerdings fände ich einen Verweis zwischen den Kontrakten des
CodeAdapter und Versionierungskomponente unnötig kompliziert, oder?
In so einem Scenario stellt sich mir die Frage ob es nicht besser wäre
ein Entitäten Assembly für die „SubDomaine“ „SourceCodeManagement“ zu
erstellen um unnötige Referenzen zu vermeiden.
Oder bin ich da auf dem Holzweg?

So lange Client und Server (also Verwaltung) das VersionedItem gleich benutzen, schön und gut. Aber da fängt es schon an: Nimm als Beispiel Subversion: VersionedItem könnte eine Methode Delete() besitzen. Delete() markiert das VersionedItem als gelöscht, so dass es in der aktuellen und zukünftigen Revisionen nicht mehr auftaucht.

Der Cliententwickler hat aber zusätzlich die Anforderung, die Datei zu löschen. Er implementiert genau das in Delete...den Rest kannst Du Dir denken.

Was aber geht: Gemeinsamkeiten, insbesondere Properties in einem Interface IVersionItemInfo hinterlegen, damit Client und Server auf gleiche Schnittstellen zugreifen können und konsistente Daten haben.

-Markus

[Sebastian Jancke]

Bei " Client und Server" und "Konsistenz" wäre ich vorsichtig...