Domain Driven Design Model

[Generic1]

Hallo,

ich möchte eine einfache Registrierung machen, bei der sich eine Person mit den wichtigsten Parametern (Vor-, Nachname, Geb. Datum und einer Nummer -> Objekt Person ist also ein Entity- Objekt im DDD Sinn) anmelden kann und dies dann in einer Datenbank- Tabelle gespeichert wird.
Ich bin jetzt gerade dabei, mir ein Model für das zu machen und hab mal unteren Vorschlag bin aber nicht zufrieden, da die Klasse "Person" niergends vorkommt.
Auch bin ich mir nicht sicher ob ein Service in DDD Sinn ein Repository verwenden kann/darf.
Was sagt ihr dazu, bin euch dankbar für jeden Tipp in diese Richtung!
Beste Grüße,

 

[Generic1]

OK, Services sind ein eigenständiges Konstrukt der Domain Driven Design und greifen nicht auf Repositories zu, das hab ich jetzt nachgelesen,
von dem her ist die Zeichung oben schon mal falsch.
Wie könnte man das dann darstellen, um dem DDD zu genügen und vor allem, wie kann ich die Klasse Person in das Model integrieren?

 

[Generic1]

OK, wahrscheinlich ist die Frage nicht zu beantworten.
Besten Dank trotzdem fürs drüberschaun, ich werds mal mit try an error versuchen.

 

[bygones]

mein wissen von ddd ist noch rudimentaer, daher eher halbwahrheiten:

"Person" ist doch deine Domain oder ? das hat dann zugriff auf eine (Person)Registry.
Service sind auf Applikationsebene (Transaktionshandling etc), nicht auf Domainebene.

oeh... gibts eigentlich noch ne frage ?!

 

[mvitz]

Jetzt wo sich der erste mit Halbwissen traut, traue ich mich auch

Sehe das eigentlich auch so wie bygones. Person ist/gehört zur Domain. Evtl. sogar als Aggregate-Entity. Eine Person bekommt man über ein PersonRepository.

Laut Evans (habe gerade nachgeschaut P. 104 Englische Version) braucht man Services ja dann nur noch, um Domain Aktivitäten durchzuführen, die nicht natürlich in ein Objekt passen. Hierzu würde ich z.B. das speichern einer Person zählen (außer man benutzt hier ActiveRecord).

 

[Generic1]

Kein Problem wenns halbwissen ist, hilft mir trotzdem weiter!!

Also grundsätzlich sehe ich das auch so, man benötigt einen service wenn man man gewisses Verhalten nicht einer Entity oder eines VO zuweisen kann, Services gehören aber meiner Meinung nach definitiv zum Domain- Layer und nicht zum Application - Layer (ausser ich hab da was falsch verstanden).

Mein Frage wäre jetzt, wie ich das Model von oben ändern muss, damist die Entity- Klasse Person (Person gehört zur Domain -> würd ich auch sagen) auch mit im Speil ist?
PS: den Service muss man sich wegdenken, der gehört so definitiv nicht zum Model.

 

[mvitz]

Das hängt mit Sicherheit auch davon ab, welches Persistenzframework man benutzt. Wir brauchen definitiv:

class Person { }

mit den dazugehörigen Attributen. Jetzt ist eine Registration ja im Endeffekt ein erstmaliges Anlegen einer Person. Insofern müsste man das ganze dann wohl doch in einen Service lagern. Evtl. so

class RegisterService {
  void register(Person person) {
    personRepository.save(person);
  }
}

Wobei ich mir dort nicht sicher bin, ob ein Repository sowas wie save kennen sollte. Ansonsten ginge noch so etwas wie

class RegisterService {
  Person register(String vorname, String nachname) {
    Person p = personRepository.newPerson(vorname, nachname);
    return p;
}

und dann anschließend der Person die anderen Attribute übergeben.

 

[Generic1]

Das mit dem Service dachte ich mir auch, aber schau dir mal diesen Link an:
http://www.lostechies.com/blogs/joe_ocampo/WindowsLiveWriter/ADiscussiononDomainDrivenDesign_13318/clip_image00242.jpg

Der Service steht da alleine und deshalb bin ich da wieder abgekommen, dass ein Service eine Entity verwendet.
Was sagst du dazu?

 

[Generic1]

Kann dazu noch jemand etwas sagen, wäre für jeden Tipp dankbar!!
Besten Dank,

 

[maki]

DDD untescheidet zwischen sog. Domain Services (was hier schon beschrieben wurde, eine fun ktionalität passt nicht in ein Domain Obejkt) und sog. ApplicationServices, letztere sind was auch in nicht-DDD verwendet wird (SessionBean, etc. pp.).

Das hier von mvitz (sorry) ist imho nicht richtig, zumindest für DomainServices:

class RegisterService {
  void register(Person person) {
    personRepository.save(person);
  }
}

Bei einem ApplicationService dagegen wäre das wieder ok.

Wobei ich mir dort nicht sicher bin, ob ein Repository sowas wie save kennen sollte.

Wieso dann nicht eine Methdoe register im Repo?

 

[Generic1]

Hallo maki,

könntest du ein Beispiel geben, wie so ein Service in Domain- Layer aussehen könnte und ist ein Service das Richtige in meinem Fall, ich hab ja eine Entity "Person", diese Entity soll in der DB gespeichert werden - wäre da ein Repository vorzuziehen indem das Entity "Person" auf das Repository zugreift (und sich speichert?) oder gar ein Service der eine Instance auf das Repository hat und das Repository verwaltet/speichert die Entities "Person" indem es diese Entities vom (Domain-) Service bekommt.
Besten Dank für die Hilfe!.
lg

 

[maki]

wäre da ein Repository vorzuziehen indem das Entity "Person" auf das Repository zugreift (und sich speichert?)

Nein, dass wäre das sog. "Active Record" Muster und ist genau das Gegenteil von DDD.
Peron braucht doch auhc kein PersonRepository, oder?
Deine 2. Lösung gefällt mir schon besser.

 

[Generic1]

OK, das 2. war das:
gar ein Service der eine Instance auf das Repository hat und das Repository verwaltet/speichert die Entities "Person" indem es diese Entities vom (Domain-) Service bekommt.


dsa wäre dann eh genau das, was ich ganz oben aufgezeichnet habe, oder?
für die Benennung wäre aber dann irgendwie doch "PersonRepository" und "PersonService", oder wie benennt man das ordentlich?
Besten Dank,

 

[Generic1]

Also wenn da jetzt keine Einwände kommen, dann werde ich das als meinen ersten Ansatz wählen!?
Wäre das OK für einen ersten Ansatz (meine erste Model- Zeichung ganz oben bzw. das letzte was ich geschrieben habe!?)

 

[Generic1]

OK, dann gibts wirklich keine Einwände, obwohl ich nicht ganz überzeugt bin mit dem Service!?