Mostrando postagens com marcador Arquitetura. Mostrar todas as postagens
Mostrando postagens com marcador Arquitetura. Mostrar todas as postagens

quinta-feira, 15 de junho de 2017

DDD - O Mapa



O Evans em seu livro, sugere esse mapa para demonstrar e explicar os principais elementos do DDD. Podemos dividir esse mapa em duas partes para entendê-lo melhor. Para isso, parta do elemento Model-Driven Desing e divida o mapa em duas partes: os elementos abaixo do model-driven design, e os elementos à cima.

Na parte de baixo do mapa, temos os elementos mais arquiteturais do DDD. Em DDD nós basicamente partimos de um Domínio, que é divido em Subdomínios, que serão implementados individualmente através de um Bounded Context. Teremos alguns Subdomínios especiais, como o Core Domain e o Shared Kernel. E tudo isso deve ser organizado através de um Mapa de Contexto, e sempre respeitando a tal da linguagem ubíqua (ou onipresente).

Na parte de cima temos os principais elementos e padrões utilizados na modelagem de um domínio. São as práticas mais próximas do nosso código. Através de uma arquitetura de camadas, modelamos nosso domínio com o uso de Entidades, Objetos de Valor e Agregações. Armazenamos e recuperamos dados através de Repositórios, e implementamos nossas regras de negócio com o uso de Serviços, Factories e Eventos.

Esse Mapa serve como um guia, e nos ajuda a entender como todos os conceitos sugeridos pelo DDD se relacionam. Cada um desses elementos é um capítulo à parte no DDD, e aos poucos pretendo abordá-los aqui nesse blog.

segunda-feira, 12 de junho de 2017

DDD - Bíblia ou kamasutra?




Nessa nossa área de Desenvolvimento de Software, temos o mau hábito de confundir tecnologias, linguagens e frameworks com religião. E com o DDD eu venho percebendo um pouco disso também, inclusive comparações do livro do Eric Evans com a Bíblia.

Se é para comparar o livro do Evans com algum outro livro, eu já prefiro compará-lo com o kamasutra. 

Explico:

Você não deve encarar o DDD como um conjunto de Regras a serem seguidas à risca, com penas que podem lhe levar ao inferno. Na minha opinião você deve encarar o livro do Evans, assim como qualquer outra referência do DDD, como um conjunto de boas ideias e práticas, para garantir a qualidade e o sucesso das suas aplicações.

Conforme você for estudando e adotando o DDD, irá notar que a maioria das ideias são válidas e perfeitamente aplicáveis. Porém, é bem possível que um ou outro padrão não faça sentido para o seu Domínio, ou precise de alguma adaptação para facilitar a implementação.

sábado, 10 de junho de 2017

DDD - Referências


Depois do Lançamento do Livro da Capa Azul, diversas outras vertentes e interpretações sobre DDD foram surgindo. Segue abaixo algumas das referências que considero mais relevantes:


Esse primeiro é o livro da "Ponte", de Jimmi Nilson. Ele ganhou um grande destaque pois aplicou os conceitos do Domain Driven Design, em uma Aplicação desenvolvida em .NET Framework com C#.


Já esse livro do Vaughn Vernon, trás uma abordagem atualizada sobre o tema, demonstrando exemplos práticos e de fácil entendimento.

Uma das minha referências preferidas é esse curso no PluralSight. Julie Lerman e Steve Smith mostram em vídeo, a modelagem e o desenvolvimento de uma aplicação .NET usando os conceitos do Domain Driven Design.


O Livro da Capa Azul tem uma edição traduzida em Português. Confesso que ainda não li, mas está na minha lista de leitura. Assim que tiver uma opinião a respeito, coloco minhas impressões em um novo post nesse blog.

quinta-feira, 8 de junho de 2017

O Livro da capa Azul


O termo DDD (Domain Driven Design) surgiu nesse livro da Capa Azul:


O livro é um épico da arquitetura de Software. É uma daquelas poucas referências que vai sobreviver ao tempo, e servirá de base para muita coisa no futuro. Porém, definitivamente não é um livro fácil. Eric Evans é o Tolkien do desenvolvimento de Softwate, ele meio que escreve em parábolas. :)

Brincadeiras à parte, o que tenho a dizer sobre O livro é que você precisa ler! Mas essa não deve ser a sua primeira leitura sobre DDD. Se você está começando agora, não comece pelo livro da capa azul, ele vai te trazer mais dúvidas do que certezas, e possivelmente poderá te desmotivar à entrar no mundo do DDD.

Comece por esse livro aqui:


Esse livro da InfoQ, escrito por Abel Avram e Floyd Marinescu, é considerado um Resumo do Livro do Evans, mas mais do que isso, eles conseguiram captar a essência do DDD e expor de uma forma simples e fácil de entender. Se você não tem nenhuma experiência em DDD, deve definitivamente começar por esse livro.

Outro motivo para começar por aqui é que o livro no formato PDF, é GRATUÍTO!! Então não tem desculpa, é só baixar e ler. 

Ahh, mas é em Inglês, como faço?

Bem... nesse caso só tenho uma a dizer:

Aprenda a Ler e Ouvir em Inglês o mais rápido possível! Esse é o requisito número 1 para quem quer ser um programador. As melhores referências (livros, vídeos, artigos, etc) são em Inglês. 

Para usar um termo do DDD (que veremos em um artigo futuro), o Inglês é a Ubiquotous Language do Software!

terça-feira, 6 de junho de 2017

O que é e porque devo me preocupar com DDD?



DDD significa Domain Driven Design, ou em português: Desenvolvimento Dirigido ao Domínio. A ideia é orientar todo o processo de arquitetura e modelagem do software, única e exclusivamente ao Domínio do negócio ao qual o software deverá atender. 

Ou seja, o DDD te força a manter o foco no Problema à ser resolvido, e não na forma como será implementada a Solução. Domain Driven Design é uma filosofia. 

O termo DDD e as principais ideias que o permeiam, foram cunhadas por um sujeito chamado Eric Evans, no livro Domain Driven Design – Atacando a complexidade no coração do software.

 

Esse livro está para a Orientação à Objetos assim como o livro Análise Estruturada Moderna de Edward Yourdon, esteve para Análise e Desenvolvimento de Sistemas nas décadas de 70, 80 e 90. Décadas que antecederam à popularização das Linguagens Orientadas à Objetos.



Se existe uma forma correta de arquitetar e modelar software com a Orientação à Objetos, é através do Domain Driven Design. Eric Evans sugere o seguinte Mapa para expor os elementos do DDD, e como eles se relacionam:



Não vou entrar nos detalhes do DDD nesse artigo, isso ficará parar os próximos. Mas tem uma coisa que é importante deixar claro aqui: 

Porque devo me preocupar com DDD? 

Tenha em mente que o objetivo do DDD é elevar ao máximo a tempo de vida da sua aplicação, e garantir a qualidade do código que deu origem a ela.

Pense no DDD como a melhor forma para preservar o código que você escreve, para que ele sobreviva o máximo possível ao tempo, às novas tecnologias, aos requisitos que não foram previstos, e à uma das variáveis mais impactantes no tempo de vida do software, você!