Planejando a Arquitetura
Do design centrado nos dados a orientação a domínio
Em seu trabalho, (Avram, et al., 2006) destaca que o desenvolvimento de software é, na maior parte dos casos, utilizado para automação de processos ou resolver problemas de negócio. Os processos de negócio ou problemas a serem resolvidos são o domínio do software. Nós temos que entender, desde o início, que o software é derivado deste domínio e está diretamente relacionado a ele.
Em suma, o software deve seguir o modelo do domínio. Essa é a melhor maneira de fazer o software refletir um domínio específico. Ele precisa incorporar os conceitos fundamentais e os elementos do domínio, percebendo as relações entre eles.
Arquitetura Centrada nos Dados
Podemos observar que devido à impedância entre os mundos objeto e relacional, é comum encontrarmos soluções de arquitetura onde o domínio da aplicação está fortemente acoplado a camada de acesso a dados. Essa é uma questão encontrada principalmente quando uma abordagem de arquitetura centrada nos dados é utilizada.
Nessa abordagem, a modelagem da estrutura dos dados é a peça central. O banco de dados é a parte mais importante dessa arquitetura e o Administrador de Dados desempenha um papel fundamental.
No entanto, uma abordagem centrada nos dados pode ser bem utilizada quando temos um cenário para aplicações de formulários sobre dados que não envolvam processos de negócio complexos.
Arquitetura Orientada a Domínio
Como (Avram, et al., 2006) definem, a Arquitetura Orientada a Domínio combina arquitetura e práticas de desenvolvimento. Dentre tantos fatores, eles destacam como a arquitetura e o desenvolvimento podem trabalhar juntos para criar uma solução melhor.
Dessa maneira, uma boa arquitetura vai acelerar o desenvolvimento, enquanto o feedback proveniente do processo de desenvolvimento irá melhorar a arquitetura.
Referências:
Avram, Abel and Marinescu, Floyd. 2006. Domain Driven Design Quickly. 2006.
Teu artigo me fez refletir um certo inferno que paira no mercado TI:
1) Eu vejo Model Driven Design como ferramenta importante para recém formados que aprendem na univerisdades a criar classes que misturam responsabilidade e operações. MDD é um buzz word que
deveria ser um dever e não vantagem de argumentação pois todo engenheiro de software sabe por natureza o príncipio básico de “divide-and-conquer” – Porém muitos não saibam aplicar, aí, acho que MDD é um caminho, que não é único – Erik Evans fez compilou um conhecimento importante. Arquiteturas (de software ou sistemas) orientadas a eventos – de forma monolítica ou de processos (sistêmicos) distribuídos -colocam o MDD como um paradigma passado. SOA é o melhor exemplo de estado da arte para grandes empresas continuarem a viver e não a sobriviver nas mudanças.
2) Por outro lado, O mundo orientado a objetos e qualquer metodologia mais contemporânea acaba quando se ingressa numa enterprise antiga, engessada, cheia de necessidades de atenção ao seu “contexto”, porém com GRANA. No entando, são nelas que podemos encontrar facilmente tantos processos e regras de negócio embutidos em stored procedures. O DBA se confunde com analista de processos, programador, etc.
Que nunca viu um projeto inovador virar nightmare que atire a primeira pedra.
Fico convencido que arquitetura centrada nos dados é
importantíssima no mercado, se pernsarmos bem, o mercado tem necessidade de alguns diferentes tipos de profissionais sêniores:
O dito Aquiteto de Software: que geralmente inicia projetos, faz liderança técnica e está antenado nas novas tecnologias e metodologias, – bom, o que todo mundo quer ser.
O dito Consultor, o multiciplinar pica grossa que aceita desafios e resolve problemas nos mais diferentes tipos de indústrias e tecnologias – a posição que todo mundo quer correr mas sempre acaba fazendo alguma atuação na vida – afinal todo mundo se ilude.
E os arquitetos de empresas cujo software não é produto fim, tem prioridade baixa e acabam atuando como consultores exclusivos – estes, geralmente ficam frustrados querendo mudar de vida (todo mundo já foi um dia).
Por isso, dizer que “O banco de dados é a parte mais importante dessa arquitetura…” e desqualificar acrescentado, de “…cenário para aplicações de formulários sobre dados que não envolvam processos de negócio complexos” acaba sendo um opnião surreal.
Parece que o autor não tem noção do mercado para o qual ele escreve, ou o mercado dele é diferente dos demais, ou ele quer que se faça menos aplicações centradas nos dados. Bom.. a realidade é outra, não acho que as pessoas devam criar a cultura de desimportância da arquitetura centrada nos dados, até porque tem muitos sistemas no mercado querem manutenção. Mas acho importânte se destruir a cultura de modelagem de sistemas orientada a dados.
“Deixe-nos nos objetos e terás mais lucro com vossa mais-valia!!” heheheh
viva!! valeu Milesi!!!
Eduardo Xavier
17/novembro/2010 em 21:46