admina maioria dos aplicativos de software comercial é criada com um conjunto de requisitos de negócios complexos para resolver problemas ou necessidades específicas de negócios. No entanto, esperar que todos os desenvolvedores/arquitetos de software sejam especialistas em domínios de negócios e esperar que eles conheçam funções de negócios inteiras também é impraticável. Por outro lado, como criamos um software que agrega valor e tem consumidores que precisam de automação que utilizem o software? Um aplicativo de software não pode ser apenas uma peça de excelência técnica, mas na maioria dos casos, também real e utilizável de excelência empresarial automatizada. O design e os modelos orientados por domínio são as respostas para essas perguntas.
este pequeno artigo fala sobre um dos princípios-chave do design orientado por domínio chamado “linguagem onipresente”, pois os conceitos, princípios e padrões de DDD reúnem tecnologia e excelência de negócios para quaisquer aplicativos de software sofisticados que possam ser criados e gerenciados.
Talk Ubiquitously
Ubiquitous language é um modelo que atua como uma linguagem universal para ajudar a comunicação entre desenvolvedores de software e especialistas em domínio.Colaborar, aprender e definir um modelo traz muitas barreiras iniciais de comunicação entre especialistas em software e especialistas em domínio. Portanto, evoluir o modelo de domínio com a prática do mesmo tipo de comunicação (discussões, escritos e diagramas) dentro de um contexto é fundamental para implementações bem-sucedidas, e esse tipo de conversa é chamado de linguagem onipresente. É estruturado em torno do modelo de domínio e amplamente utilizado por todos os membros da equipe dentro de um contexto limitado. Deve ser o meio ou modo para conectar todas as atividades da equipe no desenvolvimento de software. A equipe de design pode estabelecer uma compreensão profunda e conectar jargões de domínio e Entidades de software com linguagem onipresente para continuar descobrindo e evoluindo seus modelos de domínio.
|
Linguagem Universal |
Equivalente Pseudo-Código |
|
|
Nós Administrar Vacinas |
AdministerVaccines {} |
Não um núcleo de domínio, precisam de alguns detalhes mais específicos |
|
Podemos administrar as vacinas contra a gripe para pacientes |
patientNeedAFluShot() |
Melhor, pode ser faltando alguns conceitos de domínio |
|
A enfermeira administra as vacinas contra a gripe para um paciente em doses padrão |
Enfermeira->administrar a vacina(paciente, com a Vacina.getStandardDose()) |
Muito melhor, e pode ser bom para começar. |
Como podemos observar na tabela acima, existem várias maneiras de o usuário histórias (requisitos) pode ser dado, no entanto, a última linha faz sentido, já que não tem mais clareza sobre quais e como os fatores.
esperançosamente, este artigo ajuda os leitores a ter um vislumbre de como os princípios DDD defendem e ajuda a uma maior colaboração entre especialistas no assunto, analistas de negócios, partes interessadas em não Tecnologia com a comunidade técnica/de desenvolvimento para produzir sistemas complexos orientados para o domínio.