BT

Domain-Driven Design: A maneira errada

| por Jan Stenberg Seguir 29 Seguidores , traduzido por Diogo Carleto Seguir 31 Seguidores em 08 mai 2015. Tempo estimado de leitura: 2 minutos |

Segundo Gabriel Schenker, ao compartilhar sua experiência trabalhando como consultor e arquiteto de software, é comum encontrar alegações dizendo que as aplicações foram construídas usando o Domain-Driven Design (DDD), mas na verdade o seu domain model só consiste de entidades ou mesmo DTOs que separam os dados e a lógica dos serviços contendo uma mistura de lógica de negócios e infraestrutura. Nas aplicações que manipulam mensagens, essas mensagens são raramente denominadas no domínio, ao invés disso, são usados nomes genéricos que terminam com update ou modify.

Schenker, atualmente trabalha como diretor de arquitetura de software, observa que esses exageros não ocorrem apenas em aplicações antigas, porque ele frequentemente encontra esses problemas nas fases iniciais de novas aplicações. Umas das maiores razões para isso acredita Schenker, é a falta de conhecimento.

Ao trabalhar com DDD, Schenker enfatiza que nem todos os padrões do livro original de DDD do Eric Evans são igualmente importante e observa especialmente que a base do DDD é encontrada mais à frente no livro, algo que já foi reconhecido por Evans. Em contraste a estes padrões estratégicos, a primeira metade do livro é focado nos detalhes de implementação e padrões táticos.

Schenker aconselha que ao iniciar um novo projeto usando o DDD a primeira coisa a se fazer é trabalhar com os especialistas de domínio para obter um entendimento do domínio do negócio e destas discussões extrair a terminologia usada para criar um vocabulário comum que todos concordem, uma linguagem ubíqua nos termos do DDD. Seguindo isso, um complexo domínio deve ser quebrado, ao usar os especialistas no domínio, para identificar as áreas que podem ser separadas, criando subdomínios e contextos delimitados, outro termo DDD.

Outra coisa que Schenker desaconselha é a criação de um mundo centrado nos dados, começando com um modelo de dados. Ele acredita firmemente que os dados isoladamente não são nada; é necessário lógica para que os dados tenham significado, mas note também que isso vária com o contexto, portanto o contexto e a lógica devem ser o foco principal ao fazer DDD. Outro risco de quando focamos nos dados é que os bancos de dados acabam sendo usados para integração, efetivamente criando dependências entre os contextos de outra forma isoladas. Stefan Tilkov recentemente desaconselhou o uso de um modelo de dados comum.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Concordância by Higor Granzoto

Precisa melhorar a concordância das frases, não da pra entender os tópicos principais.

Re: Concordância by Erico GR

Concordo, a tradução ficou ruim :(

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

2 Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT