Muitos Engenheiros de Software, Arquitetos e Desenvolvedores, talvez, já tenham se deparado antes com a abordagem de software conhecida como DDD, Domain-Driven Design, e em muitos casos já utilizam algumas de suas técnicas e práticas;

Porém...para aqueles que ainda estão iniciando... aqui vai um pouco de teoria...são trechos que escrevi em trabalhos acadêmicos no passado...mas que podem ajudar.

>

Na definição dada por Vernon (2013), o livro escrito pelo autor original do DDD (Evans, 2003) descreve uma linguagem de padrões. Uma linguagem de padrões é um conjunto de padrões de software que estão relacionados entre si pois possuem uma dependência mútua (Vernon, 2013).

Vernon (2013) complementa a definição sobre Domain-Driven Design (DDD) quando explica que o DDD ajuda na construção de modelos de software que expressam corretamente o domínio, isto é, os conceitos e objetivos do negócio que está sendo modelado. O resultado da aplicação correta dos conceitos estudados no DDD é que o projeto de software resultante corresponde exatamente à maneira pela qual este software funciona (Vernon, 2013).

Para compreender alguns dos conceitos envolvidos no DDD é necessário recorrer a Evans (2011) para definir o termo domínio como sendo uma esfera de conhecimento, influência ou atividade na qual um software pode ser aplicado para solucionar um determinado assunto. Ainda segundo Evans (2011), o conceito de modelo diz respeito à um sistema de abstração no qual apenas alguns aspectos selecionados do domínio são descritos e então podem ser usados para resolver problemas que fazem parte daquele domínio (Evans, 2011).

Outro conceito destacado por Evans (2011) é a linguagem ubíqua que representa uma linguagem estruturada em torno do modelo do domínio e que é utilizada por todas as pessoas que integram uma equipe de desenvolvimento de software dentro de um contexto delimitado para conectar todas as atividades de desenvolvimento desempenhadas pela equipe ao software que está sendo construído.

É importante saber que contexto é um conjunto que determina o significado de uma palavra ou frase (Evans, 2011). Portanto, a expressão contexto delimitado deve ser compreendida como a descrição de uma fronteira ou limite no qual um modelo em particular é definido e aplicado (Evans, 2011).

Por fim, um resumo sobre o DDD feito por Evans (2011) é que esta é uma abordagem de desenvolvimento para softwares complexos [não é para CRUDs! ;)] em que os principais aspectos do domínio são enfatizados, os modelos são criados colaborativamente entre os especialistas do domínio e desenvolvedores de software e uma linguagem ubíqua é falada dentro de contexto delimitado explícito (Evans, 2011).

No DDD há duas formas complementares de se projetar um modelo de software. Estas formas representam técnicas de modelagem definidas como modelagem estratégica e modelagem tática e são utilizadas em conjunto com a mentalidade de desenvolvimento ágil para capturar as necessidades e objetivos do negócio, resultando em modelos de software de alta qualidade (Vernon, 2013).

...nos próximos artigos irei postar mais alguns conceitos.

Referências

Vernon, 2013: Vernon, Vaughn , Implementing Domain-Driven Design, 2013

Evans, 2003: Evans, Eric , Domain-Driven Design: Tackling the Complexity in the Heart of Software, 2003

Evans, 2011: Evans, Eric, Domain-Driven Desgin Reference, 2011