Gemeinsames Vokabular
Die Bildung eines gemeinsamen Vokabulars ist immens wichtig für den Erfolg eines Projekts. Allzu häufig nehmen Entwickler nicht an der Auftragsklärung teil und Kundengespräche bleiben dem Projektleiter vorbehalten. Dieser übernimmt eine Übersetzerrolle ein und versucht zwischen dem Vokabular des Kunden und dem der Entwickler zu vermitteln. Mit viel Glück kennt sich der Projektleiter ausreichend in der Domäne der Softwareentwicklung aus, um sich verständlich mit seinen Entwicklern auszutauschen. Dass er sich jedoch ebenso gut in dem Aufgabenbereich des Kunden auskennt, ist ziemlich unwahrscheinlich.
Entwickeln Sie mit dem gesamten Team eine universelle Sprache, die in jedem Aspekt des Projekts verwendet wird: in den Modellen, im Quellcode, der Dokumentation und in Gesprächen und Korrespondenz. Das Vokabular verfeinern Sie fortwährend und bemühen sich, Unklarheiten möglichst früh zu beseitigen.
Nachdem Sie zusammen ein erstes Modell entwickelt und sich auf die grundlegenden Begriffe geeinigt haben, sollten Sie so früh wie möglich mit der Entwicklung eines Prototypen beginnen. Der traditionelle Weg, das Design einer Software im Voraus festzulegen und dieses dann zu implementieren, birgt Risiken und berücksichtigt nicht das wertvolle Wissen, das Sie sich erst während des Projektverlaufs aneignen. Es ist nämlich keineswegs so, dass der Kunde von Anfang an genau weiß, was er will und Sie genau wissen, wie Sie diese unbekannten Anforderungen lösen werden.
Nutzen Sie also die Chance, während der Entwicklung zusammen mit Ihrem Kunden zu lernen. Bleiben Sie flexibel und stellen Sie eine Verbindung zwischen Ihrem Modell und der Implementation her. Diese Verbindung ist sehr wichtig! Nach jedem Entwicklungsschritt sollten Sie die bei der Programmierung gewonnenen Kenntnisse wieder in das Modell einfließen lassen und mit den Domänenexperten besprechen. Nicht selten erlangt der Kunde bei dieser Gelegenheit selbst einen tieferen Einblick in sein eigenes Fachgebiet.








2 Antworten
von Die Zukunft der Extension-Entwicklung: N… 01.12.2009 (09:42Uhr) 1.
[...] in abstrahierte Softwareobjekte – das Domänen-Modell („Domain Model“) – übersetzt [1]. Objekte, die explizit nicht zum Domänen-Modell gehören sind solche, die für das Speichern und [...]
von Wie am besten Extbase lernen? - TYPO3-ne… 11.11.2011 (16:11Uhr) 2.
[...] werden, der Autor hat außerdem eine Zusammenfassung veröffentlich.Domain-driven DesignEin t3n-Artikel von Robert Lemke (Team Leader FLOW3) führt in das Thema ein.Das Buch Domain-Driven Design: Tackling Complexity in [...]