Nur zur Diskussion, für mich scheint es, dass 2 verschiedene Terminologien tatsächlich dasselbe sagen. Gibt es greifbare Unterschiede zwischen diesen beiden Designansätzen?Design-Methodik: Use-Case-getrieben vs Domain-getrieben
Use Cases Fokus auf Benutzer, Aktionen, und Prozesse. Dies ist aus betriebswirtschaftlicher Sicht großartig, da jeder eine abstrahierte Sicht auf das System sehen kann.
DDD konzentriert sich auf die Erstellung von Software, die Probleme löst. Die 'Wer kann das lösen? 'und die' Welchen Prozess werden sie folgen? 'kommen nachher.
DDD wirklich bekommt, um die Kernprobleme früher im Designprozess und hilft Ihnen Struktur Ihre Lösung (dh Entities, Wert Objekte, Lagerräume, Domain/Anwendung/Infrastruktur-Services, Bounded Contexts, Spezifikationen zu identifizieren, usw.).
Use Cases Sie sorgen haupt nicht für diese, oder wie Sie Ihre Entwicklung (Anti-Korruptions-Ebenen, Separate Ways, etc)
Nach meiner Erfahrung DDD bietet mehr Flexibilität verwalten (Anforderungen ändern jemand?), und bietet die Grundlagen für Ihre Use Cases. Sobald Sie Ihr Domain Model an seinem Platz haben, können Use Cases mit Controllern/Workflow Engines/UIs, die mit Ihrem Domain Model verbinden, implementiert werden. Oft habe ich Lücken in den Geschäftsanforderungen nur durch den Aufbau von Domänenmodellen identifiziert.
Und nachdem ich vor ein paar Jahren einen Vortrag von Ivar Jacobsen besucht habe, würde ich auch sagen, dass DDD besser für Agile geeignet ist.
Für mich ist Domain-Driven Design (DDD) mehr "alles umgebend"; Use Cases sind nur ein Werkzeug, das sich auf eine bestimmte Sichtweise konzentriert: Wie reagiert etwas auf einen Stimulus und wird verwendet, um Verhaltensanforderungen festzuhalten oder zu dokumentieren?
Für mich ist der Begriff "Domäne" ein geladener - er gibt einen Überblick über alle Konzepte, die für ein bestimmtes Problemgebiet relevant sind.
Wenn Sie beschreiben, wie Teile der Domäne interagieren - insbesondere wie sie auf Stimulus reagieren, können Sie Use Cases verwenden.
Soweit ein Ansatz geht: Use Cases sind die "zusätzliche" Ansicht in der 4+1 Architectural View Model, aber sie sind nicht eine Design-Ansatz für sich.
Ein weiterer Unterschied ist, dass DDD oft sehr eng mit einem Objektorientierten Modell oder System verbunden ist; Auf diese Weise erfasst/stellt DDD (unter anderem) die Struktur eines Systems dar - etwas, was Use Cases nicht tun.
Aber sind keine Anwendungsfälle eine geführte Tour durch dieses Modell, das Domain-driven-Design angeblich baut? Und hilft Ihnen ein Drive-In-Fall nicht, die Probleme in der DDD zu finden, die Sie nicht finden würden, wenn Sie nicht auch einige Anwendungsfälle in Ihrer Entwurfsphase verwenden würden? –
Ich bin mir nicht sicher, ob UC eine "geführte Tour" ist - obwohl das nach einem nützlichen Konzept klingt. Ein UC konzentriert sich auf Verhaltensanforderungen und ist szenariobasiert - also würde es sicherlich helfen, das Domänenmodell zu "testen" und zu erklären, wie es in bestimmten Szenarien funktioniert. Ich sehe UC als Teil einer DDD - kein Äquivalent. –
Dies ist meine persönliche Interpretation basierend auf Erfahrung.
Anwendungsfallgesteuertes Design verwendet Use Case als Werkzeug zum Ermitteln der Entität, Schnittstelle, Interaktionsnachricht und des Workflows zur Ausführung bestimmter Geschäftsvorgänge. Dies wird oft in mehreren Analyse- oder Entwurfsphasen verwendet, um die Anforderungen zu erfassen oder zu verstehen und um erste Entwürfe zu erstellen. DDD dagegen ist eher auf die Implementierung ausgerichtet, mit einem starken Fokus auf die Domain-Entität und den Kontext. Es konzentriert sich detaillierter auf den Anwendungsfall, um das Modell zu definieren (z. B. Klassen, Schnittstellen) und seine Grenzen, Aggregationen, Operationen und domänenspezifische Logik zu definieren. Es folgt im Allgemeinen einigen Standardverfahren, wie man sie bei der Umsetzung angehen kann.
DDD ist besser geeignet, wenn Sie mit Projekten arbeiten, die auf eine bestimmte Domäne abzielen, wie z. B. Buchhaltung, Engineering, wo Sie voraussehen können, dass einige oder die meisten Modelle im Unternehmen komplexe Zusammenhänge und verkörpert Logik haben können. Die Wahl zwischen Use-Case-Design oder DDD hängt auch von der Verfügbarkeit der Domain-Experten ab. Wenn Sie Stakeholder mit Geschäftsanforderungen haben (nur ein paar Zugriffe auf die Domänenexperten), ist das Case-Driven-Design im Vergleich zu DDD besser geeignet.Es ist ein hohes Risiko, DDD zu übernehmen, wenn Sie nicht direkt an der Entwicklung von Domänenexperten beteiligt sind das Projekt.
Ich persönlich denke, sie beide können sie in einigen Projekten zu ergänzen, wo Sie mit Use Case Driven Design beginnen und nähern sich die Detailplanung und Umsetzung mit DDD Ansatz
Domain-driven Design versucht im Wesentlichen so zu agieren, als wüssten Sie alle möglichen Anwendungsfälle im Voraus. Definitionsgemäß ist die "Problem" -Domäne eine Gruppe spezifischer Probleme, die als Mitglieder dieser Domäne betrachtet werden.
Autsch. Sie mögen also Domain Drive Design nicht? Wird es als schädlich angesehen? –
Ich meinte das nicht im negativen Sinne. Ich denke DDD ist eine wirklich gute Idee. Aber der schwierige Teil besteht darin, die "vollständige" Menge von Anwendungsfällen im Voraus zu bestimmen. Normalerweise passiert es, dass Sie eine Annäherung erhalten (Sie können nur so viel Hellsehen haben), implementieren Sie das, und dann entdecken Sie Fälle, die Sie nicht berücksichtigt haben. Die DDD Jungs reden nicht viel über * Evolution * einer Domain nach der Implementierung, aber es passiert immer. Ich habe dafür keine guten Antworten. Nicht DDD IMHO ist eigentlich schlimmer, aber ... weil Sie die allgemeinen Anwendungsfälle nicht durchdacht haben. –
Ein wirklich gutes Beispiel, wo DDD gut funktioniert, ist, wenn Sie ein altes Produkt mit einer neuen Architektur und Dev-Plattform umgestalten. Ich war an der Überarbeitung eines großen domänenspezifischen Produkts (Entwicklung vor etwa 15 Jahren) von C nach .NET mit DDD beteiligt. –
Use Case angetrieben Ansatz funktioniert gut, wenn Sie nur ein Client für das Produkt haben und Client bereits gesagt, Sie über alle Probleme, die von Produkt gelöst werden muss. Dies ist in serviceorientierten Unternehmen generell möglich. Es wird schwierig zu verwalten, wenn Sie mehrere Clients für dasselbe Produkt haben. Dies geschieht in der Regel in Produktentwicklungsunternehmen. In solchen Fällen (Produkt Driven Companies) DDD kommt zu handlich. Sie entwickeln ein Produkt mit DDD (Sie nennen es als Basis). Dann überprüfen Sie, ob alle Anwendungsfälle für einen neuen Client anwendbar sind, wenn nicht, dann bilden Sie eine Schicht über der Basis für kundenspezifische Änderungen.
Ich glaube nicht, dass Use-Case-basiertes Design davon ausgehen muss, dass die Anwendungsfälle alle möglichen Verwendungen definieren kann nur repräsentative Verwendungen sein. – poolie
+1 für die Idee, dass einige Leute ein Produkt entwickeln, das von 100.000.000 Menschen benutzt wird, die sie nicht einzeln interviewen und diskutieren können. Trotzdem können Sie dort auch Use Cases verwenden. Sie müssen nur etwas Rollenspiel (denken Sie wie der Kunde) und Hundefutter (mit Ihrem eigenen Produkt), um gute Möglichkeiten zu finden, Use Cases in Ihrem produktorientierten Prozess zu verwenden. –
Ich bin kein Experte für diese, und diese Begriffe können unscharf sein, und verschiedene Dinge für verschiedene Menschen bedeuten. Aber ..
Ich hätte gesagt, dass ein Domain-Design war, wo es ein vorhandenes System gab (papierbasiert, manuell, was auch immer) und die Software modelliert die tatsächlichen Entitäten im System. In einem Bibliothekssystem sehen Sie sich also eine Bibliothek an und sehen, dass es Bücher und Regale, Schränke und Räume gibt. Und basierend darauf modellieren Sie die reale Domäne in der Software.
Mit Use Case starten Sie mit "Was versuchen wir zu tun?" Möglicherweise benötigen Sie in Ihrem Modell keine anderen Räume, da sie in den Anwendungsfällen nicht benötigt werden. Das macht Ihr System einfacher (und weniger fehleranfällig), aber wenn Sie nicht die "reale Welt" modellieren, verlieren Sie etwas Flexibilität.
Genau, DDD geht es darum, die Geschäftswelt so genau wie möglich zu modellieren. Wenn dieses Modell korrekt ist, wird die Unterstützung von Use Cases und die Unterstützung von Änderungen viel einfacher. Aber selbst wenn Ihr Modell zum ersten Mal nicht perfekt ist, ist ein sauberes Modell viel einfacher zu ändern und zu reparieren als eine Lösung, die in einer solchen Grundlage fehlt. – saille
In einem kürzlich erschienenen Vortrag (http://domaindrivendendesign.org/node/198) hebt Eric Evans hervor, dass Ihr erstes Domänenmodell fast immer falsch ist und am letzten Tag Ihres Projekts eher korrekt ist! In dem Wissen, dass sich das Modell * im Laufe der Zeit ändern wird, ist Flexibilität von entscheidender Bedeutung. –
So sind Use-Cases aus metaphorischer Sicht nicht "im Fahrersitz", obwohl der Use-Case als Teil des Ganzen sehr wichtig ist? Ist das nicht ein Fall, in dem DDD und UCDD nur ein Aspekt einer ganzen Softwaremethodik sind und dem einen oder anderen einen artifiziellen Primat geben, den NIEMANDEN wirklich genießt? –