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.