„Domain-Driven Design“ (Link zur deutschen Wikipedia) erscheint mir wie eine umständliche Umschreibung für „sorgfältig entwickelte Software“. Gut umgesetzte Softwarearchitektur. Das ist es, was ich schon immer so gut wie möglich zu erreichen versucht habe, seit ich beruflich Software entwickle.
Im Grunde geht es darum, genau zu verstehen, was der Endnutzer bzw. Kunde von seiner Software erwartet, und – was noch wichtiger ist – ihm dabei zu helfen, selbst zu verstehen, was er eigentlich will.
Eine der wichtigsten Aufgaben des Softwarearchitekten besteht darin, die zu automatisierenden Vorgänge in den in der jeweiligen Branche üblichen Begriffen zu beschreiben und diese Begriffe sowie ihre Attribute in einem regelmäßig aktualisierten Glossar zu definieren. Die Beschreibung der Akteure, Elemente, Aufgaben und Prozesse in einem bestimmten Szenario erfolgt mithilfe sogenannter Use-Cases, die manchmal auch als User-Stories oder User-Journeys bezeichnet werden.
Der kleinstmögliche Anwendungsfall beschreibt eine bestimmte Funktion, die sich ein Kunde in einer Software wünscht, und erzählt eine kurze Geschichte darüber, wie der Benutzer mit seinen Kollegen, der Software und der jeweiligen Funktion interagiert, um eine Aufgabe zu erledigen. Die Geschichte sollte verdeutlichen, wie die Funktion arbeitet und wie sie den Benutzer unterstützt.
Das vorrangige Ziel besteht darin, Missverständnisse zu vermeiden und die richtigen und passenden Begriffe zu finden, die eine Softwarefunktion, -eigenschaft oder ein Softwareobjekt so beschreiben, dass alle am Projekt und am Anwendungsbereich Beteiligten sie verstehen können.
„Domain Driven Design“ (Deutscher Wikipedia Link) seems to me like a convoluted phrase for „Software that is built carefully„. Well-executed Software Architecture. This is what I’ve always attempted to do as good as possible, ever since I’ve been professionally developing software.
It bascially involves fully understanding what the end-user/customer wants from his software and – more importantly – helping him/her understand what he/she wants.
Describing what is to be automated in the generic terms that the given field uses and defining them and their attributes in a regularly updated glossary is one of the most important tasks of the Software Architect. Describing the actors, elements, tasks and processes in a given scenario is done with so-called use-cases, sometimes also called user-stories or user-journeys.
The smallest possible use-case describes a certain feature a customer wants in software and tells a little story of how the user interacts with peer, the software and the specific feature to get a task done. The story should highlight how the feature works and how it enables the user.
The primary objective is to avoid any misunderstanding and to find the correct and fitting terms that describes a softwares feature, function or object in a manner, that all involved with the project and the applications domain can understand.