Interface mit Service-Layer oder Domain-Objekte selbst? (DDD),

Question

Ich lerne immer noch über DDD und ich habe diese beiden (wahrscheinlich einfach) Fragen:

Wenn eine Fabrik neues Objekt erstellt / Graph / Aggregat Instanzen, sondern auch "rekonstituiert" Objekte / Grafiken aus dem Repository , dann:

(1) Gibt es in Ihrem Service-Layer-Funktionen / Jobs / Aufgaben / unit-of-Arbeit Anruf in die Fabrik oder eine Verhaltensmethode auf der Entity-Instanz oder eine Domainservice-Funktion? Ich bin in Bezug auf den Call-Stack auf der Grundlage der Verantwortung dieser Komponenten verloren.

(2) Do Entity-Instanzen haben sogar "Verhaltensmethoden" wie oben? Zum Beispiel ist ein Beitrag hat p.UpdatePost(string bodyText) oder ist das kein Problem des Domain-Modells und so das gleiche sollte mit dem Repository erreicht werden? Oder die Service-Layer-Funktion, soll es das Repository in diesem Fall seines Aufruf und die Entity-Instanz einfach Verhalten Methoden, die spezifisch für die Domäne sind und nicht die Ausdauer? Aber dann, warum klingt es wie „Aktualisieren eine post“ ist eine Domäne-Funktion, wenn das das Ziel des Benutzers ist?

können Sie sehen, ich bin ganz über den Platz. Bitte Hilfe.

Answer 1

  

(1) Gibt es in Ihrem Service-Layer-Funktionen / Jobs / Aufgaben / unit-of-Arbeit Anruf in die Fabrik oder eine Verhaltensmethode auf der Entity-Instanz oder eine Domainservice-Funktion? Ich bin in Bezug auf den Call-Stack auf der Grundlage der Verantwortung dieser Komponenten verloren.

In der Regel - Top-Level ruft notwendig Aggregat Wurzel und ruft eine Funktion auf sich. Manchmal Top-Level ruft mehrere Aggregat Wurzeln und geben sie nicht an Domain-Service, aber nicht oft, weil Domain Service ist ein ziemlich starkes Zeichen, dass es nicht erkannte Aggregat Wurzel ist. Am Ende - Top-Level gewährleistet Aggregat Wurzel beibehalten wird

.

  

(2) Do Entity-Instanzen haben sogar "Verhaltensmethoden" wie oben? Zum Beispiel ist ein Beitrag hat p.UpdatePost (string bodytext) oder ist das kein Problem des Domain-Modells und so das gleiche sollte mit dem Repository erreicht werden? Oder die Service-Layer-Funktion, soll es das Repository in diesem Fall seines Aufruf und die Entity-Instanz einfach Verhalten Methoden, die spezifisch für die Domäne sind und nicht die Ausdauer? Aber dann, warum klingt es wie „Aktualisieren eine post“ ist eine Domäne-Funktion, wenn das das Ziel des Benutzers ist?

Ja, sie tun. Domain-Modell sollten sich bewusst von Zustandsänderungen der es sein. Und das ist viel günstiger als es auf den ersten Blick. Große daran ist, dass Sie Erweiterungspunkt zu gewinnen. Wenn Client Woche gehen wird Sie später und sagen, dass er System will zusätzliche Dinge überprüfen, wenn der Benutzer Updates posten - statt jede Zeile post.bodyText="new value" suchen, werden Sie in der Lage sein, direkt auf post.UpdatePost Methode zu gehen und befestigen notwendigen Dinge dort

Auf der anderen Seite - CRUD ist nicht gegenseitig aus mit Domain Driven Design. Z.B. - in meiner Anwendung, Verwaltung von Benutzern und ihren Rollen ist uninteressant genug, dass ich nicht einmal bin versucht, es granular zu modellieren. Sie müssen Teile erkennen, was in geschäftlichen Angelegenheiten Ihre Anwendung beschreibt und die Arbeit mit.

Beachten Sie, dass Domain-Driven Design nur Sinn für komplexe Anwendungen. Einfache Blog-Anwendung braucht es nicht.

  

(3) Bin ich falsch in der Annahme, dass eine Dienstschicht (nicht-Domänendienst) kapseln sollte, wie eine Schnittstelle interagiert mit dem Domain-Layer?

Wie ich es sehe - Anwendungsdienste mehr sind für die Orchestrierung Infrastruktur. Wenn es keine Infrastruktur beteiligt ist - dann Application Service verliert Wert :

  

Anwendungsdienste sind im Grunde nur Fassaden. Und jede Fassade ist schlecht, wenn Komplexität es Probleme Übergewichtungen fügt sie löst.

---

Innerhalb domain:

//aggregate root is persistence ignorant. 
//it shouldn't reference repository directly
public class Customer{
  public string Name {get; private set;}
  public static Customer Register(string name){
    return new Customer(name);
  }
  protected Customer(string name){
    //here it's aware of state changes.
    //aggregate root changes it's own state
    //instead of having state changed from outside
    //through public properties
    this.Name=name;
  }
}

//domain model contains abstraction of persistence
public interface ICustomerRepository{
  void Save(Customer customer);
}

Außerhalb der Domain:

public class CustomerRepository:ICustomerRepository{
  //here we actually save state of customer into database/cloud/xml/whatever
  public void Save(Customer customer){
    //note that we do not change state of customer, we just persist it here
    _voodoo.StoreItSomehow(customer);
  }
}

//asp.net mvc controller
public class CustomerController{
  public CustomerController(ICustomerRepository repository){
    if (repository==null)throw new ArgumentNullException();
    _repository=repository;
  }
  public ActionResult Register(string name){
    var customer=Customer.Register(name);
    _repository.Save(customer);
  }
}