Serviceorientierte Architektur und domänengestütztes Design

Question

Ich habe Code immer in SOA-Art entwickelt. In diesem Jahr habe ich versucht, mehr DDD zu machen, aber ich habe immer das Gefühl, dass ich es nicht verstehe. Bei der Arbeit sind unsere Systeme lastausgeglichen und so konstruiert, dass sie keinen Zustand haben. Die Architektur ist:

Webseite

=== Physical Layer ==

Main-Service

== Physical Layer ==

Server 1/Service 2/Service 3/Dienstleistung 4

Nur Server 1, Service 2, Service 3 und Service 4 können mit der Datenbank kommunizieren, und der Hauptservice ruft den richtigen Service basierend auf den bestellten Produkten auf. Jede physische Ebene ist ebenfalls lastausgleichend.

Jetzt, wenn ich einen neuen Dienst entwickle, versuche ich DDD in diesem Dienst zu denken, obwohl es nicht wirklich wie es passt fühlt.

ich gut DDD Prinzipien wie Entitäten, Werttypen, Repositories, Aggregate, Fabriken usw.

ich auch versucht habe ORM verwenden, aber sie scheinen einfach nicht, wie sie eine stateless Architektur passen. Ich weiß, dass es Möglichkeiten gibt, zum Beispiel IStatelessSession anstelle von ISession mit NHibernate zu verwenden. Allerdings fühlen sich ORM einfach so, als würden sie nicht in eine staatenlose Architektur passen.

Ich habe bemerkt, dass ich wirklich nur einige der Konzepte und Muster verwende, die DDD mir beigebracht hat, aber die Gesamtarchitektur ist immer noch SOA.

Ich fange an zu denken, DDD passt nicht in große Systeme, aber ich denke, einige der Muster und Konzepte passen in große Systeme.

Wie ich schon sagte, vielleicht fasse ich DDD einfach nicht oder bin vielleicht gerade dabei, meine Designs zu analysieren? Vielleicht, indem ich die Muster und Konzepte benutze, die DDD mir beigebracht hat, benutze ich DDD? Ich bin mir nicht sicher, ob es wirklich eine Frage zu diesem Beitrag gibt, sondern mehr über die Gedanken, die ich hatte, wenn ich herausfinden wollte, wo DDD in Gesamtsysteme passt und wie skalierbar es wirklich ist. Die Wahrheit ist, ich glaube nicht, dass ich wirklich weiß, was DDD ist?

Answer 1

Die wichtigsten Dinge über Domain-Driven Design sind die großen Bildideen:

• die allgegenwärtige Sprache,
• die strategische Entscheidungsfindung, wo Sie einen Mehrwert, indem sie in der Kerndomäne arbeiten (und sich von anderen bösartigen Systemen zu isolieren), und
• der Ansatz, um testbare, flexible Designs durch Entkoppeln von Infrastruktur von Geschäftslogik zu machen.

Diese sind breit anwendbar und sind die wertvollsten Stücke.

Es gibt eine Menge Design-Muster Zeug über Fabriken, Dienstleistungen, Repositories, Aggregate, etc. Ich nehme das als Rat von einem erfahrenen Entwickler zum anderen, nicht als Evangelium, weil so viel davon abhängig variieren kann die Sprache und die Frameworks, die Sie verwenden. Imho neigen sie dazu, überbetont zu werden, weil Programmierer wie wir detailorientiert sind und wir auf diese Art von Dingen besessen sind. Es gibt dort auch wertvolle Dinge, aber es muss relativiert werden.Es kann also sein, dass ein Teil davon für Sie nicht relevant ist oder dass er bei der Arbeit mit Ihnen wächst.

Also ich würde sagen, es ist nicht wie es eine Checkliste ist, die Sie durchlaufen können, um sicherzustellen, dass Sie alle Muster verwenden, es ist eine Sache, das große Bild im Auge zu behalten und zu sehen, wie dies Ihre Vorgehensweise bei der Entwicklung von Software ändert . Und wenn Sie ein paar gute Tipps von den Mustern nehmen, ist das auch toll.

Speziell in Bezug auf die SOA-Sache habe ich Anwendungen entwickelt, die ihren gesamten Status auf die Datenbank verschieben, die Persistenz-ignorante Domänenobjekte verwendet haben. Das Schreiben von Tests für Dienste, die Daos vortäuschen und Dinge zurückgeben müssen, ist Plackerei. Je mehr Logik ich in die Domain-Objekte einbringen kann, desto weniger muss ich mich mit Mocks in meinen Diensten herumschlagen, also mag ich diesen Ansatz besser.

Answer 2

Ich denke, ein gängiges Missverständnis ist, dass SOA und DDD zwei widersprüchliche Stile sind.

IMO, das sind zwei Konzepte, die gut zusammen funktionieren; Sie erstellen ein Domänenmodell, das Ihre Domänenkonzepte kapselt und Einstiegspunkte über Dienste in das Modell einblendet.

Ich sehe auch nicht, was das Problem mit ORM und Diensten ist, können Sie einfach eine Sitzung/Uow pro Service-Aufruf verwenden. Modellieren Sie Ihre Dienstvorgänge einfach als atomare Domänenbefehle.

ein naives Beispiel:

[WebMethod] 
void RenameCustomer(int customerId,string newName) 
{ 
    using(var uow = UoW.Begin()) 
    { 
     var customerRepo = new CustomerRepo(uow); 
     var customer = customerRepo.FindById(customerId); 
     customer.Rename(newName); 
     uow.Commit(); 
    } 
} 

Vielleicht ist das Problem, das Sie konfrontiert sind, ist, dass man Dienste wie „UpdateOrder“ zu schaffen, die einen Auftrag Einheit nimmt und versuchen, diese in einer neuen Sitzung zu aktualisieren?

Ich versuche diese Art von Diensten zu vermeiden und zerlege diese stattdessen in kleinere atomare Befehle.

Jeder Befehl kann als Operation verfügbar gemacht werden, oder Sie können eine einzelne Dienstoperation ausführen, die Gruppen von Befehlen empfängt und diese dann an Befehlshandler delegiert.

IMO, so können Sie Ihre Absichten besser aussetzen.

Answer 3

Es gibt einige mit DDD eingeführte Konzepte, die Sie beim Erstellen von SOA verwirren können.

Ich muss mit another answer völlig zustimmen, dass SOA-Dienste Operationen offen legen, die als atomare Befehle fungieren. Ich glaube, dass eine sehr saubere SOA Nachrichten anstelle von Entitäten verwendet. Die Service-Implementierung verwendet dann das Domänenmodell, um die Operation tatsächlich auszuführen.

Allerdings gibt es ein Konzept in DDD namens "Domain-Service". Dies unterscheidet sich geringfügig von einem Anwendungsdienst. In der Regel wird ein "Domänenservice" in der gleichen allgegenwärtigen Sprache wie der Rest des Domänenmodells entworfen und stellt Geschäftslogik dar, die nicht sauber in eine Entität oder einen Wert passt.

Ein Domain-Service sollte nicht mit einem Application Service verwechselt werden. Tatsächlich kann ein Anwendungsdienst sehr gut so implementiert werden, dass er einen Domänen-Dienst verwendet. Schließlich können die Anwendungsdienste das Domänenmodell in SOA vollständig einkapseln.