Entschuldige jede Ignoranz hier, ich bin ziemlich neu in DDD, also sei sanft.
Ich arbeite an einem großen konfigurationsgesteuerten Datenverwaltungssystem. Das System wird durch Spezifizieren von Konfigurationselementen (wie Geschäftsregeln, Prozessen und Validierungen) in einer externen Syntax erstellt. Sagen wir einfach, dass die Syntax ein Konglomerat aus Groovy basierten DSL und Drools war.
Ich mag die Ideen der Einfachheit, die DDD bietet, indem ich Infrastrukturbelange spezifisch von den Kernkonzepten der Domäne abtrenne.
Allerdings habe ich Schwierigkeiten, einige der Konzepte von DDD aufgrund der konfigurierbaren Natur des Systems anzuwenden. Sowohl Verhalten (Prozesse), Validierung und Geschäftsregeln sind außerhalb des Systems definiert. Daher haben die Entitäten in der Domäne intrinsisch kein eigenes Verhalten. Sie sind eher die "Validator" -Ding oder die "Rules Engine" oder die "Workflow Engine".
Ich werde das mit einem Beispiel verdeutlichen. Nehmen wir an, mein System verwaltet Mitarbeiter für ein Unternehmen. Ohne zu viel darüber nachzudenken, würden Sie sich vorstellen, dass ich in meiner Domäne eine Mitarbeiter-Entität und eine Unternehmens-Entität habe.
Nach DDD versuche ich ein Szenario zu modellieren, in dem ein Mitarbeiter befördert wird. Möglicherweise wird eine neue Methode auf dem Mitarbeiter namens promote (Employee.promote) angezeigt. Wir könnten eine Geschäftsregel haben, die angibt, dass ein Mitarbeiter nicht zweimal im selben Jahr befördert werden kann (ja, das ist alles erfunden). Ich könnte also etwas haben wie:
%Vor%Nun, in der Anwendung, mit der ich arbeite, würde diese Geschäftsregel auf eine Regel-Engine ausgelagert werden. Nach DDD könnte ich etwas tun wie:
%Vor%Um meine Regeln zu externalisieren. Das System ist jedoch wesentlich allgemeiner. Die "Promotion" -Operation selbst wird als "Prozess" durch externe Konfiguration definiert. Also würde ich zur Kompilierzeit nicht einmal wissen, ob ich für diesen Mitarbeiter eine "Promotion" -Operation zur Verfügung habe. So wird mein Mitarbeiter-Objekt aus einer Code-Perspektive ziemlich leer und delegiert alle Funktionen an die Konfiguration. Es könnte etwa so aussehen:
%Vor%Oder alternativ
%Vor%Meine Frage ist: macht DDD in dieser Anwendung überhaupt Sinn? Soll ich stattdessen nur die Zusammenarbeit von Prozessen, Validierungen, Geschäftsregeln (Rules Engine) im Nicht-DDD-Sinn modellieren?
Ich mag die Zwiebel-Architektur und kann UI - & gt; App-Dienste - & gt; Kern - & gt; Infrastruktur, um eine gute Trennung der Anliegen zu gewährleisten. Aber der Kern könnte die oben erwähnten Kollaborateure sein, im Gegensatz zu echten "Domänenkonzepten".
Ein Teil von mir glaubt, dass in diesem Fall die "Domänenkonzepte" die Validierer, Prozessoren und Geschäftsregeln sind, weil sie die allgegenwärtige Sprache bilden, über die wir sprechen, wenn wir unser System diskutieren. In diesem Fall hätte ich Entitäten ohne echtes Verhalten (zum größten Teil) und Domänenkonzepte in Bezug auf Prozessoren, Validatoren, Rules Engine, die das Verhalten im System realisieren.
Hinzufügen ein wenig mehr Info. Angesichts meiner obigen Frage arbeitete ich an einer Lösung, die wie folgt aussehen würde:
org.beispiel.app
org.beispiel.domäne - Mitarbeiter - Unternehmen - EmployeeLevel
org.example.domain.shared - Prozess - Geschäftsregel - Validator
org.example.infrastructure
Hoffentlich fügt dieser kleine Ausschnitt ein wenig Klarheit hinzu.
Die Konzepte "Process", "BusinessRule" und "Validator" würden also innerhalb der Domäne liegen, würden aber das Domänenmodell in Bezug auf die Dinge unterstützen, die das System tut.
Aus Wikipedia:
Domain-driven Design (DDD) ist ein Ansatz zur Entwicklung von Software für komplexe Bedürfnisse durch die tiefe Verbindung der Implementierung mit einem sich entwickelnden System Modell der Kerngeschäftskonzepte .
Ich glaube, dass Validierer, Prozess, Regel nicht Ihre Kerngeschäftskonzepte sind. Das sind ziemlich häufige Software-Abstraktionen.
Ich bin kein großer Fan von DDD "by the the Book", aber um "domänengetriebener" zu sein, sollten Ihre DSL und Ihre Regeln tatsächlich um Ihre Geschäftskonzepte herum gebaut werden, um mehr Sinn zu geben.
Unter der Haube können Sie immer noch Validatoren, Prozesse, Manager, Executors usw. verwenden, aber Ihre DSL / Regeln werden besser lesbar sein, wenn Sie Geschäftskonzepte und keine Software-Abstraktionen verwenden.
AKTUALISIERT : Da Sie Groovy zur Definition Ihrer DSL verwenden, können Sie die dynamische Namenserweiterungs- und Builder-Funktionalität von Groovy verwenden, um lesbare Regeln und Klassen zu erstellen. Sie können auch das "convention over configuration" -Prinzip nutzen, um einige Logik einzubinden. Zum Beispiel können Sie in Groovy versuchen, etwas ähnliches zu konstruieren:
%Vor% is ist eine Methode für ein Basisdomänenobjekt, das nach der Existenz von beispielsweise der EmployeePromotableValidator-Klasse sucht, die selbst auch eine Groovy-Klasse sein kann, die Groovys DSL-Ausdruckskraft nutzt.
start ist eine Methode in Ihrem Basisregel-Skript, die nach EmployeePromotionProcess klasse sucht, die wiederum eine Groovy-Klasse sein kann.
Das Spezifikationsmuster ist in diesem Fall sehr einfach, weil es im Grunde Teil der Sprache wird:
%Vor%Im Allgemeinen können DSLs mit Hilfe von (halb-) funktionalen Sprachen wie Groovy / Scala verwendet werden, um Software-Abstraktionen zu verbergen und Ihre Geschäftslogik im Code stärker hervorzuheben. Mit einfachem Java wirst du am Ende mit einer Menge Code auf dem Kesselschild enden, der schließlich all deine Absichten verbergen wird.
Es hängt davon ab, was genau Ihre Geschäftsdomäne ist.
Wenn Sie große zusätzliche konfigurierbare crm etwas Konstruktor machen alles tun - dann ist Ihre Geschäftsdomäne darum, dies zu ermöglichen, daher Substantive wie Process , Executors usw. sind Teil Ihrer Domäne.
Wenn Sie eine Anwendung erstellen, die Informationen über Mitarbeiter und deren Werbekampagnen verfolgen soll, dann dreht sich Ihre Geschäftsdomäne um Mitarbeiter, Gehaltsschecks, Leistungsmessungen. In diesem Fall behandeln Sie Process , Executors und ähnliche Objekte als Eindringlinge für Ihre Domain.
Auf einer bestimmten Ebene - selbst die Programmiersprache selbst ist ein invasives Werkzeug, das die Problemlösung, die Sie in Ihrem Kopf zeichnen, verwischt. Aber es ist notwendig - sonst könntest du es nicht materialisieren.
Tags und Links domain-driven-design rules