BT

Início Notícias Domain-Driven Design: A maneira errada

Domain-Driven Design: A maneira errada

Favoritos

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.

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

Comentários da comunidade

  • Concordância

    by Higor Granzoto /

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

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

  • Re: Concordância

    by Erico GR /

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Concordo, a tradução ficou ruim :(

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

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

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.