Importanza del linguaggio Ubiquitous in Domain-Driven Design

La maggior parte delle applicazioni software commerciali vengono create con una serie di requisiti aziendali complessi per risolvere problemi o esigenze aziendali specifiche. Tuttavia, aspettarsi che tutti gli sviluppatori di software / architetti siano esperti sui domini aziendali e aspettarsi che conoscano intere funzioni aziendali è anche impraticabile. D’altra parte, come si fa a creare software che porta valore e ha i consumatori che hanno bisogno di automazione che utilizzerà il software? Un’applicazione software non può essere solo un fiore all’occhiello dell’eccellenza tecnica, ma nella maggior parte dei casi, anche reale e utilizzabile dell’eccellenza aziendale automatizzata. Il design e i modelli domain-driven sono le risposte a queste domande.

Questo breve articolo parla di uno dei principi chiave del Domain-Driven Design chiamato “Ubiquitous Language”, poiché concetti, principi e modelli DDD uniscono tecnologia e eccellenza aziendale a qualsiasi sofisticata applicazione software che può essere creata e gestita.

Talk Ubiquitously

Ubiquitous language è un modello che funge da linguaggio universale per aiutare la comunicazione tra sviluppatori software ed esperti di dominio.

Collaborare, imparare e definire un modello porta molte barriere di comunicazione iniziale tra specialisti del software ed esperti di dominio. Quindi l’evoluzione del modello di dominio con la pratica dello stesso tipo di comunicazione (discussioni, scritti e diagrammi) all’interno di un contesto è fondamentale per implementazioni di successo, e questo tipo di conversazione è chiamato Linguaggio onnipresente. È strutturato attorno al modello di dominio e ampiamente utilizzato da tutti i membri del team all’interno di un contesto limitato. Dovrebbe essere il mezzo o la modalità per collegare tutte le attività del team all’interno dello sviluppo del software.

Il team di progettazione può stabilire una profonda comprensione e collegare i gerghi di dominio e le entità software con un linguaggio onnipresente per continuare a scoprire ed evolvere i loro modelli di dominio.

Onnipresente Lingua

Equivalente Pseudo Codice

Si somministrano Vaccini

AdministerVaccines {}

Non un nucleo di dominio bisogno di alcuni dettagli più specifici

Abbiamo amministrare il vaccino antinfluenzale per i pazienti

patientNeedAFluShot()

Meglio, può essere mancano alcuni concetti di dominio

L’infermiera somministra vaccini antinfluenzali a un paziente in dosi standard

Infermiere- > somministrare il vaccino (paziente, Vaccino.Otteneredose standard())

Molto meglio, e può essere buono per cominciare.

Come osserviamo nella tabella sopra, ci sono vari modi in cui le storie degli utenti (requisiti) possono essere fornite; tuttavia, l’ultima riga ha senso in quanto ha più chiarezza su cosa e come fattori.

Si spera che questo articolo aiuti i lettori a dare un’occhiata a come i principi DDD sostengono e aiutano una maggiore collaborazione tra esperti in materia, analisti aziendali, stakeholder non tecnologici con la comunità tecnica/di sviluppo per produrre complessi sistemi domain driven.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.