Bedeutung der ubiquitären Sprache im Domain-Driven Design

Die meisten kommerziellen Softwareanwendungen werden mit einer Reihe komplexer Geschäftsanforderungen erstellt, um spezifische Geschäftsprobleme oder -bedürfnisse zu lösen. Es ist jedoch auch unpraktisch, zu erwarten, dass alle Softwareentwickler / -architekten Experten für Geschäftsbereiche sind und erwarten, dass sie ganze Geschäftsfunktionen kennen. Auf der anderen Seite, wie schaffen wir Software, die Wert bringt und Verbraucher hat, die Automatisierung benötigen, die die Software verwenden werden? Eine Softwareanwendung kann nicht nur ein Prunkstück technischer Exzellenz sein, sondern in den meisten Fällen auch eine echte und nutzbare automatisierte Business Excellence. Domain-Driven Design und Modelle sind die Antworten auf diese Fragen.

Dieser kurze Artikel spricht über eines der Schlüsselprinzipien des Domain-Driven Designs, das als „Ubiquitous Language“ bezeichnet wird, da DDD-Konzepte, -Prinzipien und -muster Technologie und Business Excellence für alle anspruchsvollen Softwareanwendungen zusammenbringen, die erstellt und verwaltet werden können.

Ubiquitär sprechen

Ubiquitäre Sprache ist ein Modell, das als universelle Sprache dient, um die Kommunikation zwischen Softwareentwicklern und Domänenexperten zu unterstützen.

Die Zusammenarbeit, das Lernen und die Definition eines Modells bringen viele anfängliche Kommunikationsbarrieren zwischen Softwarespezialisten und Domänenexperten mit sich. Daher ist die Entwicklung eines Domänenmodells mit der gleichen Art von Kommunikation (Diskussionen, Schriften und in Diagrammen) in einem Kontext für erfolgreiche Implementierungen von größter Bedeutung, und diese Art von Konversation wird als ubiquitäre Sprache bezeichnet. Es ist um das Domänenmodell herum strukturiert und wird von allen Teammitgliedern in einem begrenzten Kontext umfassend verwendet. Es sollte das Medium oder der Modus sein, um alle Aktivitäten des Teams innerhalb der Softwareentwicklung zu verbinden.

Das Designteam kann ein tiefes Verständnis aufbauen und Domänen-Jargons und Software-Entitäten mit allgegenwärtiger Sprache verbinden, um ihre Domänenmodelle weiter zu entdecken und weiterzuentwickeln.

Allgegenwärtige Sprache

Äquivalenter Pseudocode

Wir verabreichen Impfstoffe

VerwalteriMpfungen {}

Keine Kerndomäne – benötigen Sie spezifischere Details

Wir verabreichen Grippeimpfungen an Patienten

Patientenbedürfnisflush()

Besser, kann sein fehlen einiger Domänenkonzepte

Die Krankenschwester verabreicht einem Patienten Grippeimpfstoffe in Standarddosen

Krankenschwester-> Impfstoff verabreichen (Patient, Impfstoff.Standarddosierung())

Viel besser, und kann gut sein, mit zu beginnen.

Wie wir in der obigen Tabelle beobachten, gibt es verschiedene Möglichkeiten, wie die User Stories (Anforderungen) angegeben werden können; Die letzte Zeile ist jedoch sinnvoll, da sie mehr Klarheit darüber bietet, welche und wie Faktoren.

Hoffentlich hilft dieser Artikel den Lesern, einen Einblick in die DDD-Prinzipien zu erhalten, und unterstützt eine engere Zusammenarbeit zwischen Fachexperten, Geschäftsanalysten und nichttechnologischen Interessengruppen mit der technischen / Entwicklungsgemeinschaft, um komplexe domänengesteuerte Systeme zu erstellen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.