De como criar aplicações
utilizando técnicas como o DDD (Domain Drive Design), TDD (Test Drive Development),
e IoC (Inversion of Control). Além de mostrar uma alternativa aos bancos
relacionais, o banco NoSQL RavenDB. Todas essas técnicas serão exploradas no
contexto do artigo. O tema é útil no desenvolvimento de sistemas que tenham a
necessidade de serem flexíveis, de fácil manutenção e de fácil evolução. Resumo do DevMan Quando surge a ideia de
construir um sistema, espera-se um sistema robusto, eficiente, flexível, de
fácil manutenção e evolução. Mas atualmente não é o que tem se encontrado no
cenário atual de sistemas de software. Existem índices que apontam para um
percentual de apenas 34% de sucesso em projetos de software. Projetos que
começam, mas não terminam, concluídos, mas que não atendem o negócio ou não sai
da maneira que o cliente espera, enfim, existem os mais variados estados ruins
que se possa imaginar. O objetivo principal deste artigo, é mostrar técnicas de
como ter um software de qualidade que utilize um banco de dados NoSql, aplicando
boas práticas de desenvolvimento. Desta forma, você pode ter aplicações de
fácil manutenção, flexibilidade e aderente a mudanças.
Em que situação o tema é útil
São vários aspectos que precisam ser levados em consideração na hora de arquitetar uma solução. Fatores como o ambiente, mecanismo de persistência, se esta será desktop ou web, o que o sistema se propõe a fazer etc. A construção de um bom software não é das tarefas mais fáceis, não é algo que se constrói com facilidade. E infelizmente o mercado demorou muito para entender isto. O que temos no cenário atual são aplicações tão mal escritas, que se gasta mais para manter do que para evoluir, e isso quando é possível evoluir.
Depois de muito “apanhar” das surpresas que um software mal escrito proporciona, tem se visto um esforço muito grande para mudar este quadro, haja vista, que somente aproximadamente 34% dos projetos de software em todo mundo tem sucesso; esta estatística preocupante, fez com que o mercado olhasse com mais atenção às técnicas de desenvolvimento e engenharia de software que até então não eram tão utilizadas. Conceitos como injeção de dependência, inversão de controle, DDD, BDD, TDD e padrões de projeto e arquitetura vêm ganhando mais aderência no mercado e produzindo excelentes resultados. Dependendo do tamanho e da complexidade do sistema, será inviável desenvolvê-lo sem boas práticas e, caso seja feita a tentativa de não utilizá-las ou ignorá-las, o resultado será catastrófico.
Aplicações estáveis, por onde começar?
É uma pergunta normal que nos últimos anos sempre recebia a mesma resposta: pela modelagem dos dados! Vamos pensar e analisar a seguinte questão: se o sistema irá atender a um negócio específico, por que começa-lo pela maneira como os dados serão persistidos? Por que não começar pela estratégia de como o negócio será expresso? Começar pelo banco de dados é um erro que por muitos anos vem sendo cometido. O fato de modelar os dados e construir o sistema baseado na modelagem feita, causa um problema comum, que é a possibilidade da modelagem mudar e esta mudança impactar no sistema, e muita das vezes com um alto grau de impacto.
Domain Drive Design é uma técnica que surgiu pela autoria de Eric Evans e que vai contra o que tem sido feito por longos anos, que é o fato de representar um determinado negócio em tabelas de banco de dados, ao invés de expressar através de objetos. Ele foca em expressar o negócio em questão, foca em utilizar a fundo a orientação a objetos e colocar o domínio do problema como o coração da aplicação e não mais apenas os dados que são mantidos. Domínio é o termo utilizado por Evans para definir o que ele chama do coração de um software de negócio. O domínio é composto pelas classes que irão representar o negócio do cliente.
A grande realidade é que a abordagem relacional não é eficaz para expressar as ideias de um determinado negócio. Um ramo de negócio pode ser complexo ao extremo para ser expresso somente em tabelas que contém linhas e colunas, é necessário muito mais do que isso. A essa incompatibilidade é dada o nome de impedância relacional, que é a diferença dos dois mundos, o orientado a objetos e o mundo relacional.
Um dos grandes desafios enfrentados nos últimos anos é criar meios de permitir que estes dois mundos consigam se comunicar, mesmo “falando” línguas diferentes, mesmo que tenham conceitos diferentes. Foi aí que surgiram os ORMs que são frameworks de desenvolvimento concebidos sobre alguns padrões de arquitetura, que mapeiam objetos em tabelas do banco de dados, o que é obrigatório quando você desenvolve um sistema orientado a objetos e quer persistir estes em um banco de dados relacional.
Aplicando DDD
Domain-Driven Design é a forma de se construir software orientando toda a atenção para o domínio da aplicação. O domínio da aplicação é o contexto em que o software irá trabalhar. Se você vai fazer um software para controle de uma farmácia, todos os processos que envolvem o funcionamento da mesma fazem parte do domínio.
Quando você utilizar o DDD, não deve começar a aplicação pelo modelo do banco de dados, mas sim começar a modelar um domínio.
Um domínio contem todas as regras de negócio que determinam o comportamento que a aplicação deverá ter.
...
