Design Dirigido ao Domínio - DDD

Transcrição

1 Design Dirigido ao Domínio - DDD Daniel Alcântara Cordeiro, Frederico A. Lima Junior, Saulo Mendonça Universidade Salvador (Unifacs) Edf. Civil Empresarial. Rua Doutor José Peroba, nº 251, STIEP, Salvador BA - Brasil dc79.alcantara@gmail.com, fredericoalj@gmail.com, saulomb@gmail.com Abstract: The complexity of software development is usually tied to its domain, which makes the understanding of the domain essential for the creation of quality software. The domain driven design have this goal, to put focus on understanding the domain. This paper provides a introduction to the basic concepts of this development philosophy, the allows the creation of systems based on the domain model. Resumo: A complexidade do desenvolvimento de um software está normalmente ligada ao seu domínio, o que torna essencial a compreensão do domínio para a criação de um software de qualidade. O design dirigido ao domínio tem este objetivo, de colocar o foco do entendimento do domínio. Este artigo apresenta uma introdução dos conceitos básicos desta filosofia de desenvolvimento, os quais permitem a criação de sistemas com base no modelo de domínio. 1. Introdução O processo de desenvolvimento de um software de natureza complexa pode ser auxiliado por diversas técnicas diferentes, sejam elas metodologias que visem facilitar o processo de planejamento e execução, ou tecnologias que focam em automatizar o processo de codificação. Entre elas temos os princípios da programação orientada a objetos e do design e modelagem do software. Mas independente do método utilizado, a complexidade do sistema estará sempre presente, pois normalmente ela depende do próprio domínio. O domínio, neste caso, refere-se ao campo de atuação do negócio, e com isso das necessidades que este negócio possui e que originaram o desenvolvimento do software em si. Logo, compreender o domínio da aplicação é compreender a complexidade desta. Então para a criação de um bom software complexo, devemos focar no domínio em questão ao utilizar esses diferentes métodos possíveis. O Design Dirigido ao Domínio (Domain Driven Design) ou DDD como é normalmente abreviado, possui este objetivo, de estabelecer o domínio como o centro do desenvolvimento do software. É apresentado na forma de uma filosofia, e que foi baseada no resultado de mais de vinte anos de trabalho, resumidas em um conjunto de padrões e boas práticas para o desenvolvimento de software a partir da modelagem do domínio. Neste contexto, o presente artigo objetiva apresentar os conceitos básicos inerentes ao DDD, focando na importância do uso destes princípios, a fim de prover um texto de fácil leitura e compreensão, que possa ajudar no processo desenvolvimento de softwares de domínio complexo.

2 Este artigo está organizado da seguinte forma: a seção 2 apresenta a historia do DDD, e a importância do domínio e modelo; na seção 3 aborda o conceito da linguagem ubíqua; na seção 4 discorre-se sobre os princípios do design dirigido ao modelo; já a seção 5 apresenta a estrutura da arquitetura em camadas; na seção 6 aborda as formas de expressar o modelo e a utilização de módulos; e por fim, na seção 7, são apresentadas as considerações finais do artigo. 2. Historia e Conceitos Fundamentais de DDD O termo Domain-Driven Design e a sigla DDD foi originalmente apresentada por Eric Evans em seu livro "Domain-Driven Design - Atacando as Complexidades no Coração do Software", que teve como objetivo, segundo o próprio autor [Evans 2003], descrever um conjunto de padrões e boas práticas com base em sua experiência no desenvolvimento de sistemas complexos e modelagem do domínio. Segundo Evans (2003), o coração do software está na habilidade de resolver os problemas relacionados ao domínio. Sendo as demais funcionalidades agindo como suporte. Onde o termo domínio refere-se aos processos e problemas derivados do mundo real que levaram a criação do software. Esta ideia fica clara quando consideramos que um dos principais objetivos para a criação de um software é à automação de um processo que existe no mundo real, assim como prover soluções para problemas de negócios reais. Podemos concluir então, conforme [Avram e Marinescu 2006], que a origem de um software está firmemente ligada ao seu domínio. Relacionar o domínio com o software pode ser um processo difícil. Software é código, e quando pensamos em código pensamos em objetos e métodos. Pensamos em tecnologia, pensamos no processo de criação do software. Mas como criar algo que não sabemos como funciona? Um bom exemplo foi apresentado por [Avram e Marinescu 2006] ao perguntar como criar um software complexo para um sistema de banco? Não é possível criar um sistema para um banco sem saber como um banco funciona. E quem entende de banco não vai ser o desenvolvedor do software, ou o arquiteto ou o analista, mas o banqueiro. Ou seja, para criarmos um sistema complexo necessitamos de entender o domínio do sistema, e para entender o domínio do sistema, precisamos trabalhar em conjunto com alguém que entenda o domínio. Sabendo da importância de saber o domínio, vem à questão de como usar este conhecimento. O domínio é a representação de algo real, logo não é simplesmente convertido para código, a não ser que seja criada uma abstração para o mesmo [Avram e Marinescu 2006]. Esta abstração se torna a base da compreensão do domínio, e está sempre evoluindo. Para o DDD está abstração é um modelo, ou seja, o modelo do domínio. Segundo [Evans, 2003], o modelo não é necessariamente um diagrama, mas a ideia que o diagrama deve prover. Que pode ser representada de diversas formas, seja o próprio diagrama, como um código ou uma descrição. 3. Linguagem Ubíqua Com o entendimento de que para criar um software precisamos entender o domínio, e para conhecer o domínio precisamos trabalhar com um especialista do domínio,

3 devemos considerar como realizar a comunicação com este especialista. Segundo [EVANS, 2003], o especialista no domínio pode não entender dos jargões técnicos inerentes ao desenvolvimento de software, assim como o desenvolvedor pode não entender dos jargões que são utilizados naquele domínio. Um diagrama criado por um desenvolvedor pode não ser entendido pelo especialista do domínio, ou até entendido de forma equivocada, ou o mesmo problema pode ser representado de forma diferente por diferentes desenvolvedores. Para resolver este tipo de problema, o DDD orienta na utilização de uma linguagem em comum entre ambas as partes, o que pode ser chamada de linguagem ubíqua ou linguagem onipresente. O DDD orienta que a criação desta linguagem seja baseada no modelo do domínio, pois é à base do sistema, onde o software e o domínio se encontram [Avram e Marinescu 2006]. Essa linguagem dever ser utilizada em todas as comunicações e no código, sabendo que alterações na linguagem são alterações no modelo [Evans 2003], garantindo maior integridade na comunicação e melhor entendimento do código. 4. Design Dirigido por Modelo Visto a importância da compreensão do domínio e na criação de um modelo que servirá como base para a criação do software, a próxima etapa será a transição do modelo para código. Vimos que escrever código sem o conhecimento do domínio é pouco eficaz, mas de nada adianta ter um modelo de domínio complexo se este não for corretamente utilizado na codificação. Segundo Evans (2003), este problema normalmente ocorre ao separar o processo de modelagem com o de design, como ocorre em muitas das metodologias de design de software. Nestas metodologias, a orientação é na criação de um modelo de análise, com o objetivo de representar os conceitos do domínio, e posteriormente a criação do design, que será utilizando na codificação. A ideia é de utilizar o modelo de análise para criar o design. O problema está no fato que o modelo de análise não é feito pensando no design, e ambos são normalmente feitos por pessoas diferentes, causando uma perda de informação nesta transição. O DDD sugere então que a criação do modelo do domínio e o design do software sejam interligados, o que é feito ao utilizar o design dirigido por modelo (Model-Driven Design), que segundo Evans (2003), descarta a necessidade de um modelo de análise e outro de design, ao procurar um único modelo que sirva para ambos os casos. A ideia é escolher um modelo que possa ser expresso em software, para que o design possa ser baseado no modelo [Avram e Marinescu 2006]. A escolha e desenvolvimento de um modelo que possa atender as necessidades da análise, design, e que ainda suporte a utilização de uma linguagem ubíqua, não é uma tarefa fácil. Para tal, o DDD sugere um conjunto de padrões que, utilizado, permitem a representação do modelo em código de forma eficaz. A Figura 1 apresenta quais são os principais padrões utilizados no DDD e como eles se relacionam entre si.

4 5. Arquitetura em camadas Figura 1. Relação entre os padrões do DDD Compreendendo, então, a necessidade da criação do modelo de domínio no DDD, a primeira etapa no desenvolvimento, está no isolamento do domínio. Evans (2003) analisa o fato de que a parte do software responsável por resolver problemas do domínio é normalmente uma pequena parte de todo o sistema, apesar de grande importância. Pois além das regras de negócio, o software depende de outros elementos, como interface, banco de dados, interação com usuário e comunicação com outros sistemas. O que ocorre, então, é que os problemas do domínio são normalmente codificados diretamente nestes elementos. Criando uma dependência entre as regras de negócio e grande parte do código. Ocasionando pequenas alterações no domínio podem gerar alteração em todo o código. O DDD utiliza então a técnica de divisão de software conhecida como Arquitetura em Camadas, cujo princípio é que elementos de uma camada dependem apenas dos elementos da mesma camada, ou de uma camada abaixo dela [Evans 2003]. As camadas, conforme [Evans 2003], são divididas em: Camada de Interface: Responsável por mostrar a informação e interpretar os comandos, seja de um usuário ou de outro sistema. Camada de Aplicação: Responsável por coordenar as atividades do sistema, porém não contem regras de negócio. Camada de Domínio: Contém as informações do domínio, no estado e das regras de negócio. É a camada principal no sistema. Camada de Infraestrutura: Funciona como suporte para demais camadas. Sendo responsável pela comunicação entre as camadas, e prove persistência.

5 6. Expressando o Modelo e Utilizando Módulos Conforme a figura 1. O Design dirigido por Modelo pode ser expresso de diferentes formas, sendo elas: Entidades: Muitos objetos não são definidos pelos seus atributos, mas por possuir uma identidade que se mantém ao longo da execução do sistema. Estes objetos são chamados de Entidades [Evans 2003]. A identidade de um destes objetos pode possuir diferentes formas, seja chave primaria de um banco de dados, ou um ou mais atributos do próprio objeto. Entidades são importantes na modelagem do domínio, e devem ser consideradas no início do processo de modelagem. [Avram e Marinescu 2006]. Objetos de Valor: Ao contrário das entidades, alguns objetos não possuem identidades, sendo apenas os atributos deste objeto que interessa, ou seja, são objetos que representam um aspecto descritivo do domínio. Estes objetos são chamados de Objetos de Valor [Evans 2003]. Recomenda-se que Objetos de Valor sejam imutáveis, criados no construtor, e na necessidade de ser atribuído um novo valor, que seja criado um novo objeto [Avram e Marinescu 2006]. Serviços: Alguns elementos do domínio não se encaixam nos conceitos de entidades e objetos de valor. São aqueles que realizam atividades e ações, que em código podem necessitar de mais de um objeto ou classe para serem representados. Estes elementos que se encaixam nesta categoria são chamados de Serviços [Evans 2003]. O modelo de uma aplicação complexa pode tornar-se muito grande, trazendo problemas, como ilustrados por Avram e Marinescu (2006), como na dificuldade de falar sobre o modelo num todo, e entender o relacionamento e interação entre diferentes partes. Necessita-se então que o modelo seja dividido em partes, ou seja, organizado em Módulos, onde a escolha de como dividir o sistema objetive que os módulos tenham alta coesão e baixo acoplamento entre si, e que para melhor entendimento, sejam nomeados conforme as definições da linguagem ubíqua. 7. Conclusão Este artigo resumiu os principais conceitos relacionados ao domain-driven design, apresentando praticas já adotadas e que podem trazer benefícios para o desenvolvimento de softwares complexos. Esperamos que os princípios abordados neste artigo ajudem na compreensão do que é o DDD, e de como pode ser útil e aplicável em projetos de software. Maiores aprofundamentos podem ser obtidos com a leitura do livro de Eric Evans que é a base do DDD. Referências Evans, Eric. (2003), Domain-Diven Design: Tackling Complexity in the Heart of Software, Addison Wesley, 1ª edição Avram, Abel e Marinescu, Floyd. (2006), Domain Driven Design Quickly, C4MEDIA, Disponível em: