Also habe ich diese Frage von einem der Entwickler in meinem Team bekommen: Was ist domänengesteuertes Design? Ich könnte natürlich auf das Buch von Evans zeigen, aber ist das eigentlich eine Antwort?Was ist domänengesteuertes Design?
Wie würden Sie DDD in wenigen Sätzen den Junior Software Engineers in Ihrem Team erklären?
Ich würde sagen, diese Praxis fördert die Konzentration Ihrer Bemühungen auf den "Problemraum" und nicht auf den "Lösungsraum". Eine emergente Lösung (das Design) entwickeln, indem man die Domain studiert und wirklich lernt und versteht. Eine der Übungen (aus XP) wäre das Schreiben von Stories, die in der Problemdomäne vorkommen. Aus diesen können Sie Ihre Anwendungsfälle und Objekte für Ihr Design identifizieren. Sie "tauchen auf" und sagen Ihnen, was in der Lösung sein muss und wie sie miteinander interagieren müssen.
Ein wichtiger Teil von DDD ist die so genannte ubiquitäre Sprache; sprich die gleiche Sprache wie die Business-Experten. Und machen Sie Ihren Code/Ihre Architektur so, dass sie diese Sprache widerspiegelt, um Impedanzprobleme zu vermeiden.
Soweit ich es verstehe, sprechen die Programmierer nicht die Sprache der Domänenexperten, sondern eine gemeinsame Sprache. – sumek
@sumek versucht, Leute dazu zu bringen, sich auf eine * gemeinsame Sprache * zu einigen, ist die Mühe wahrscheinlich nicht wert. Es braucht eine Menge Zeit, um ein Geschäft dazu zu bringen, ** irgendetwas ** zuzustimmen. Nach meiner Erfahrung ist es normalerweise am besten, sich an den bestehenden Jargon anzupassen, das heißt, wenn Sie pünktlich liefern wollen ... – MattDavey
Bei der Entdeckung der "Domäne" bilden Sie eine gemeinsame Sprache, die sowohl die Entwickler als auch alle anderen Beteiligten im Projekt verstehen.
Das Domain-Modell und seine "Lingo" ist im Quellcode für das fertige Produkt durchaus beobachtbar. Das ist zumindest meine Erfahrung
Der Versuch zu verstehen, was die Software, die Sie schreiben, ist über und spiegelt dieses Verständnis im Modell.
InfoQ hat ein kostenloses E-Book:
Es ist ein gutes Buch mit vielen Beispielen.
Es ist sehr gut und prägnant. Neue Entwickler unseres Teams müssen es heute lesen. – Hace
Beim domänengesteuerten Design geht es darum, die Komplexität einer Anwendung im Domänenmodell zu verwalten, wo sie am einfachsten zu destillieren ist.
Es ist sehr schwierig, in ein paar Satz zu beschreiben, aber ich würde das InfoQ Buch als eine gute Einführung empfehlen. Ich habe auch von vielen Leuten gehört, die einen Buchclub mit Evans 'DDD-Buch gemacht haben, was viel dazu beigetragen hat, es zu verstehen.
DDD hat sich sehr bewegt, seit das blaue Buch vor 10 Jahren geschrieben wurde. Damals war ein Rich-Domain-Modell wirklich die einzige Möglichkeit, die geschäftliche Komplexität zusammenhängend zu erfassen. Heutzutage haben wir einige weitere Optionen wie CQRS und Event Sourcing, so dass die alte Vorstellung, DDD == Rich Domain Model, nicht wahr ist. Ich weiß zu schätzen, dass diese Antwort selbst vor 5 Jahren geschrieben wurde. – MattDavey
Für mich ist die nächste Ebene von OOD/OOP, wo die Kapselung ist alles über den Problembereich, wie beschrieben und von den Benutzern verstanden, und nicht so sehr über die technische Umsetzung.
Read "An Introduction to Domain Driven Design" für eine schnelle, aber detaillierte Einführung in DDD
> Moderator Anmerkung: Link nicht mehr relevant Besuch sein kann [http://dddcommunity.org] (http://dddcommunity.org/)/ – cvs