Ich habe ein wenig über Domain Driven Development gelesen, kann aber nicht sehen, wie dies wirklich irgendwelche Entwicklungspraktiken ändern würde, außer vielleicht, dass wir unsere Domain-Objektnamen mit Elementen in unseren Anforderungsdokumenten synchronisiert halten.Welche Übungen verwenden Sie nach dem Lesen von DDD?
Für die wirklich in DDD, wie hat dies Ihre Entwicklungspraktiken verändert?
Das, was ich über DDD gefunden habe, ist, dass es nur die Konzepte und Prinzipien benennt, die ich schon benutzt habe. Um nützlich zu sein, muss es die Art und Weise, wie wir Systeme entwickeln, nicht ändern, es kann uns nur die Terminologie liefern, um unseren Ansatz zu diskutieren.
Die wenigen Dinge, die für mich geändert, nachdem Domain Driven Design schnell zu lesen sind:
ich aggregare Wurzeln jetzt identifizieren, Organisationen und Werttypen.
Ich habe das Repository-Muster zusammen mit nHibernate für die Implementierung der Persistenzschicht angenommen. (Dies liegt daran, dass sich dieses ORM bei der Implementierung von Aggregatgrenzen als gut für mich anfühlt)
Ich umarme die Verwendung einer allgegenwärtigen Sprache, der Sie sich entziehen (wahrscheinlich die wichtigste Änderung, die ich vorgenommen habe).
Darüber hinaus hat DDD nur formalisiert, was ich als gesunden Menschenverstand dachte.
das könnte dich interessieren, wenn du es nicht schon gesehen hast- http://ayende.com/Blog/archive/2009/04/17/repository-is-the-new-singleton.aspx – RichardOD
@RichardOD - danke dafür . Denkanstoß auf jeden Fall ... – danielfishr
+1 Ich kann deiner Antwort nicht mehr zustimmen. Ich arbeite nicht mit .Net, aber alles andere gilt. Um DDD effektiv anzuwenden, müssen Sie Ihre eigenen Erfahrungen bei der Diskussion jedes Themas erkennen. Evans Buch ist ein wertvolles Werkzeug, um über die Themen nachzudenken, mit denen Sie bereits in realen Projekten konfrontiert sind. – JuanZe
Nicht ganz ein Antwort auf Ihre Frage, aber ...
Sie über einen Schlüsselpunkt beschönigt haben: eine Person/Team erstellt den Inhalt für Ihre Anforderung Dokumente. Aber wie kamen sie zu den Schlussfolgerungen in diesem Dokument? Präsentieren sie Fakten oder nur ihr Verständnis des Problembereichs. Ist es möglich, dass Teile des Dokuments falsch sind? Oder dass sich die Anforderungen seit der Erstellung des Dokuments geändert haben?
Tatsache ist, DDD tritt in vor Sie beginnen, Code zu schreiben. Eric Evans schlug nicht vor, dass DDD ein solider Weg ist, Code zu schreiben; DDD ist ein solider Weg zu identifizieren Sie das Geschäftsproblem, und bringen Klarheit zu den beteiligten Personen. Der Implementierungsteil ist sekundär.
Wenn Sie in einer Position sind, wo jemand andere genaue Anforderungen erstellt, und Sie eine Lösung codieren, dann großartig. Aber wenn Sie in einer Position sind, wo Sie müssen die Anforderungen verstehen (und Sie sind nicht ein Experte in der Geschäftsdomäne), dann kann die grundlegende Essenz von DDD ändern Sie Ihren Ansatz.
+1. Große Frage. – RichardOD