O que é Design Orientado a Domínio?

Alguém pode explicar (em termos sucintos) o que exatamente é o design orientado a domínio? Eu vejo bastante o termo, mas realmente não entendo o que é ou o que parece. Como ele difere do design não orientado a domínio?

Além disso, alguém pode explicar o que é um objeto de domínio? Como o domínio difere dos objetos normais?

EDITAR:

Como esse parece ser o melhor resultado do Google e minha resposta abaixo não é, consulte esta resposta muito melhor:

https://stackoverflow.com/a/1222488/1240557

RESPOSTA ANTIGA (não tão completa :))

Para criar um bom software, você precisa saber do que se trata esse software. Você não pode criar um sistema de software bancário, a menos que tenha um bom entendimento sobre o que é bancário, é preciso entender o domínio bancário.

De: Design Orientado a Domínio por Eric Evans.

Este livro faz um bom trabalho ao descrever o DDD.

Registre-se para baixar um resumo do livro ou faça o download diretamente do resumo .

O Design Orientado a Domínio é uma prescrição de metodologia e processo para o desenvolvimento de sistemas complexos cujo foco é mapear atividades, tarefas, eventos e dados dentro de um domínio de problema para os artefatos de tecnologia de um domínio de solução.

A ênfase do Design Orientado a Domínio é entender o domínio do problema para criar um modelo abstrato do domínio do problema que pode ser implementado em um conjunto específico de tecnologias. O Design Orientado a Domínios como uma metodologia fornece diretrizes sobre como esse desenvolvimento de modelo e desenvolvimento de tecnologia pode resultar em um sistema que atenda às necessidades das pessoas que o utilizam, além de ser robusto diante da mudança no domínio do problema.

O lado do processo do Design Orientado a Domínio envolve a colaboração entre especialistas em domínio, pessoas que conhecem o domínio do problema e especialistas em design / arquitetura, pessoas que conhecem o domínio da solução. A idéia é ter um modelo compartilhado com linguagem compartilhada, para que as pessoas desses dois domínios diferentes, com suas duas perspectivas diferentes, discutam a solução e, na verdade, discutam uma base de conhecimento compartilhada com conceitos compartilhados.

A falta de um entendimento compartilhado do domínio do problema entre as pessoas que precisam de um sistema específico e as pessoas que estão projetando e implementando o sistema parece ser um impedimento essencial para projetos bem-sucedidos. O Domain Driven Design é uma metodologia para lidar com esse impedimento.

É mais do que ter um modelo de objeto. O foco é realmente sobre a comunicação compartilhada e o aprimoramento da colaboração, para que as necessidades reais do domínio do problema possam ser descobertas e uma solução apropriada criada para atender a essas necessidades.

Design orientado a domínio: o bom e o desafiador fornece uma breve visão geral com este comentário:

O DDD ajuda a descobrir a arquitetura de nível superior e a informar sobre a mecânica e dinâmica do domínio que o software precisa replicar. Concretamente, isso significa que uma análise DDD bem feita minimiza mal-entendidos entre especialistas em domínio e arquitetos de software e reduz o número subseqüente de solicitações caras de mudança. Ao dividir a complexidade do domínio em contextos menores, o DDD evita forçar os arquitetos do projeto a projetar um modelo de objetos inchado, que é onde se perde muito tempo na elaboração dos detalhes da implementação - em parte porque o número de entidades com as quais lidar frequentemente cresce além do tamanho dos quadros brancos da sala de conferências.

Consulte também este artigo Design orientado a domínio para arquitetura de serviços, que fornece um pequeno exemplo. O artigo fornece a seguinte descrição em miniatura do Design Orientado a Domínio.

O Design Orientado a Domínio defende a modelagem com base na realidade dos negócios como relevante para nossos casos de uso. Como agora está ficando mais velho e o nível de hype está diminuindo, muitos de nós esquecemos que a abordagem DDD realmente ajuda a entender o problema em questão e a projetar software para o entendimento comum da solução. Ao criar aplicativos, o DDD fala sobre problemas como domínios e subdomínios. Descreve etapas / áreas independentes de problemas como contextos limitados, enfatiza uma linguagem comum para falar sobre esses problemas e adiciona muitos conceitos técnicos, como entidades, objetos de valor e regras raiz agregadas para dar suporte à implementação.

Martin Fowler escreveu vários artigos nos quais o Domain Driven Design como metodologia é mencionado. Por exemplo, este artigo, BoundedContext , fornece uma visão geral do conceito de contexto limitado do Domain Driven Development.

Naqueles dias mais jovens, éramos aconselhados a construir um modelo unificado de toda a empresa, mas o DDD reconhece que aprendemos que "a unificação total do modelo de domínio para um sistema grande não será viável ou econômica" 1 . Então, em vez disso, o DDD divide um grande sistema em Contextos limitados, cada um dos quais pode ter um modelo unificado - essencialmente uma maneira de estruturar o MultipleCanonicalModels.

Você PODE SOMENTE entender o design orientado por domínio, compreendendo primeiro o que são os seguintes:

O que é um domínio?

O campo para o qual um sistema é construído. Administração de aeroportos, vendas de seguros, cafeterias, vôo orbital, você escolhe.

Não é incomum que um aplicativo abranja vários domínios diferentes. Por exemplo, um sistema de varejo on-line pode estar trabalhando nos domínios da remessa (escolhendo maneiras apropriadas de entrega, dependendo dos itens e do destino), preços (incluindo promoções e preços específicos do usuário, por exemplo, local) e recomendações (calculando produtos por histórico de compras).

O que é um modelo?

"Uma aproximação útil para o problema em questão." - Gerry Sussman

Uma classe Employee não é um funcionário real. Ele modela um funcionário real. Sabemos que o modelo não captura tudo sobre funcionários reais, e esse não é o objetivo. Ele serve apenas para capturar o que nos interessa no contexto atual.

Domínios diferentes podem estar interessados ​​em diferentes maneiras de modelar a mesma coisa. Por exemplo, o departamento salarial e o departamento de recursos humanos podem modelar funcionários de maneiras diferentes.

O que é um modelo de domínio?

Um modelo para um domínio.

O que é Design Orientado a Domínio (DDD)?

É uma abordagem de desenvolvimento que valoriza profundamente o modelo de domínio e o conecta à implementação. O DDD foi criado e inicialmente desenvolvido por Eric Evans.

Selecionado daqui

Aqui está outro bom artigo que você pode conferir no Domain Driven Design . se sua inscrição for algo sério que não seja um trabalho na faculdade A premissa básica é estruturar tudo em torno de suas entidades e ter um modelo de domínio forte. Diferencie entre serviços que fornecem itens relacionados à infraestrutura (como envio de email, dados persistentes) e serviços que realmente fazem as coisas que são seus principais requisitos de negócios.

Espero que ajude.

Como no TDD e no BDD, você / equipe concentra-se mais no teste e no comportamento do sistema do que na implementação do código.

De maneira semelhante, quando o analista de sistemas, o proprietário do produto, a equipe de desenvolvimento e, claro, o código - entidades / classes, variáveis, funções, processos de interfaces com o usuário se comunicam usando a mesma linguagem, denominada Design Orientado a Domínio

DDD é um processo de pensamento. Ao modelar um design de software, você precisa manter o domínio / processo de negócios no centro das atenções, em vez de estruturas de dados, fluxos de dados, tecnologia, dependências internas e externas.

Existem muitas abordagens para modelar o systerm usando DDD

• fonte de eventos (usando eventos como uma única fonte de verdade)
• bancos de dados relacionais
• bases de dados de gráficos
• usando linguagens funcionais

Objeto de domínio:

Em palavras muito ingênuas, um objeto que

• tem nome com base no processo / fluxo de negócios
• tem controle completo sobre seu estado interno, ou seja, expõe métodos para manipular o estado.
• sempre preencha todos os invariantes / regras de negócios no contexto de seu uso.
• segue o princípio de responsabilidade única

O DDD (design controlado por domínio) é um conceito útil para analisar os requisitos de um projeto e lidar com a complexidade desses requisitos. Antes disso, as pessoas estavam analisando esses requisitos considerando os relacionamentos entre classes e tabelas e, de fato, seu design era baseado em tabelas de banco de dados. relacionamentos não é antigo, mas tem alguns problemas:

• Em grandes projetos com requisitos complexos, não é útil, embora seja uma ótima maneira de projetar para pequenos projetos.

• Quando você está lidando com nenhuma pessoa técnica que ela não possui conceito técnico, esse conflito pode causar grandes problemas em nosso projeto.

Portanto, o DDD lida com o primeiro problema ao considerar o projeto principal como um domínio e dividir cada parte desse projeto em pequenos pedaços que somos famosos pelo Contexto Encadernado e cada um deles não tem influência em outros. E o segundo problema foi resolvido com uma linguagem onipresente, que é uma linguagem comum entre os membros da equipe técnica e os proprietários do produto, que não são técnicos, mas têm conhecimento suficiente sobre seus requisitos.

Geralmente, a definição simples para Domínio é o principal projeto que gera dinheiro para os proprietários e outras equipes.

Acredito que o seguinte pdf lhe dará uma visão geral. Design orientado a domínio por Eric Evans

NOTA: Pense em um projeto no qual possa trabalhar, aplique as pequenas coisas que você entendeu e veja as melhores práticas. Também o ajudará a aumentar sua capacidade de abordagem da arquitetura de micro serviços.

Eu não quero repetir as respostas dos outros, então, em resumo, explico alguns mal-entendidos comuns

• Recurso prático: PADRÕES, PRINCÍPIOS E PRÁTICAS DO PROJETO CONDUZIDO POR DOMÍNIO por Scott Millett
• É uma metodologia para sistemas de negócios complicados. Leva todos os assuntos técnicos ao se comunicar com especialistas em negócios
• Ele fornece uma compreensão abrangente dos negócios (modelo simplificado e destilado) de toda a equipe de desenvolvimento.
• mantém o modelo de negócios sincronizado com o modelo de código usando linguagem onipresente (a linguagem entendida por toda a equipe de desenvolvimento, especialistas em negócios, analistas de negócios, ...), usada para comunicação dentro da equipe de desenvolvimento ou com outras equipes
• Não tem nada a ver com gerenciamento de projetos . Embora possa ser perfeitamente usado em métodos de gerenciamento de projetos como o Agile.

• Você deve evitar usá-lo em todo o seu projeto

  O DDD enfatiza a necessidade de concentrar mais esforço no subdomínio principal. O subdomínio principal é a área do seu produto que fará a diferença entre ser um sucesso e ser um fracasso. É o ponto de venda exclusivo do produto, a razão pela qual ele está sendo construído e não comprado.

  Basicamente, é porque leva muito tempo e esforço. Portanto, é recomendável dividir todo o domínio em subdomínio e apenas aplicá-lo naqueles com alto valor comercial. (por exemplo, não no subdomínio genérico, como email, ...)

• Não é uma programação orientada a objetos. É principalmente uma abordagem de solução de problemas e ( às vezes ) você não precisa usar padrões de OO (como o Gang of Four) em seus modelos de domínio. Simplesmente porque não pode ser entendido pelos especialistas em negócios (eles não sabem muito sobre fábrica, decorador, ...). Existem até alguns padrões no DDD (como O script de transação, módulo de tabela) que não estão 100% alinhados com os conceitos de OO.