2017-02-15 3 views
0

Ich versuche, DDD im folgenden Muster zu folgen.DDD - Geschäftsentscheidungen basieren auf Datenbanklogik

Controller-----DataContract----> Domain Layer (DDD) 

Controller-----Domain Object---> Repository---Entity--->EntityFramework 

Wie Sie im obigen Diagramm zu sehen, die Domänenschicht ist unabhängig Entscheidungen zu treffen, aber in meinem Fall, sind die meisten der Geschäftsentscheidungen im laufenden Betrieb genommen. Zum Beispiel

if(Account Number Associated?) 
    Load CustomerDetails //A database call is needed 
    .... 
    ..... 
    if(Has customer another loan) 
      ..... 
      ..... 
      Load other loan details //A database call is needed 
      ..... 
      ..... 
      if(Was that repaid?) 
       .... 
       .... 
       Load collateral details //A database call is needed 
       ..... 
       ..... 
       Calculate collateral details and return. 
      else 
       Load other data //A database call is needed 
     else 
      Load other data //A database call is needed 

else 
    Load other data //A database call is needed 

Wie Sie das obige Beispiel zu sehen, wird die Anwendung macht viele Geschäftsentscheidungen im laufenden Betrieb von Datenbank Anrufe. Da Domain-Layer sollte nicht von der Repository-Schicht abhängen, weiß ich nicht weiter.

I Anwendungsdienst für Datenbank-Anrufe verwenden können, aber dann Domain-Layer würde jede Logik darin nicht haben. Die gesamte Logik würde in den Application Service gehen.

Bitte helfen Sie mir dabei.

-Pandian

Antwort

3

Es gibt mindestens drei mögliche Wege aus

1) Gestalten Sie Ihr Repository auf einmal das gesamte Aggregat zu laden. Dieser Ansatz gibt dem Domänenmodell alle Zustände, die er möglicherweise sofort benötigt, statt zu versuchen, den Zustand bei Bedarf zu laden.

2) Führen Sie die Abfragen im App-Service aus und übergeben Sie die Daten an das Domänenmodell. Im Idealfall tun Sie dies im Voraus (damit Sie einen einzelnen Anruf in das Domänenmodell tätigen). Wenn dies jedoch nicht sinnvoll ist, müssen Sie dem App-Dienst vom Domänenmodell mitteilen, welche Daten benötigt werden, und der App-Dienst erkennt dies Daten und gibt es zurück.

3) Übergeben Sie ein Repository in das Domänenmodell, damit es die benötigten Daten lesen kann. Dies ist im Wesentlichen das "Domain Service" -Muster, wird aber verwendet, um auf einen Datenspeicher zuzugreifen.

In diesem Entwurf definiert das Domänenmodell die Repository-Schnittstelle und die Anwendung stellt die Implementierung bereit. Mit anderen Worten, wir verwenden das Service-Provider-Muster, um die Abhängigkeitspfeile in die richtige Richtung zu halten.

+0

Hallo @ VoiceOfUnreason, Danke für die Hilfe. Die ersten beiden Ansätze sind in meinem Fall nicht möglich. Könnten Sie mich bitte auf einige GitHub/Code-Beispiele für diese Art von "Domain Service" hinweisen? Auch wenn Sie sagen "Anwendung bietet die Implementierung" bedeutet "** Application Service ** bietet die Implementierung" richtig? – Pandiarajan

1

@Pandiarajan Domänenebene kann Domänenmodelle (Entitäten, Wertobjekte), Domänenservices und Domänenereignisse enthalten.

Aus dem obigen Code können Sie einen Domänen-Service erstellen, der all diese Domänenlogik und Konzepte, die nicht natürlich als Wertobjekte oder Entitäten modelliert sind, kapselt. Dieser Domänenservice kann ein Repository verwenden, das alle Datenbankaufrufe verarbeitet.

Beachten Sie auch, dass die Daten, die Sie zurückgeben möchten, nur Lese- oder Berichtszwecken dienen. Daher sollten Sie nach CQRS als Alternative suchen. In CQRS können all diese Leseabfragen Ihre Domänebene beim Präsentieren von Daten umgehen. Mit CQRS müssen Sie Ihre Daten nicht in ein Domänenmodell umwandeln.

+0

Könntest du mir bitte helfen, indem du ein paar Beispielprojekte in Github oder irgendwo zeigst? – Pandiarajan