Ouvi falar de Desenvolvimento Orientado a Domínio de um desenvolvedor na área. Ele falou como se fosse apenas a bala de prata para mudar os requisitos.
Eu li o wiki . Ainda não está muito claro. O que é "3D" em termos práticos? É realmente incrível que agora o diagrama de classes UML esteja obsoleto?
Respostas:
Bem, primeiro de tudo, não acho que o artigo da Wikipedia a que você se refere seja muito bom, principalmente porque faz referência a várias coisas que são apenas auxiliares ao Design Orientado a Domínio e pouco faz para esclarecer alguém sobre a prática.
Mas, como alguém que levou o Design Orientado a Domínio a sério (o que geralmente vale pelo DDD, e não pelo 3D, pelo que vale a pena), sempre achei que os fundamentos do DDD são óbvios, se você ler tanto quanto o primeiro capítulo de Eric Livro de Evans. Mas é um conjunto de padrões e práticas, portanto, não é tão fácil fornecer um resumo de três frases sobre o que é e quais são as vantagens sem entrar em detalhes. Quais detalhes ressoam com qualquer pessoa podem também ser muito diferentes; é provável que dez anos atrás eu não tivesse entendido nada disso.
DDD não é uma bala de prata. Quando feito de maneira sensata, trata-se de adotar uma abordagem artesanal para criar software e reconhecer a necessidade de reduzir o atrito cognitivo entre as equipes de desenvolvimento e as empresas para as quais estão construindo o software. Uma das práticas mais importantes é ter uma camada na qual o vocabulário de domínio usado pela equipe de software e pela equipe de negócios corresponda o mais próximo possível. Você constrói essa camada de forma iterativa ao entender o problema de negócios que está tentando resolver. Quando a lógica de negócios é sensivelmente codificada nessa camada, isolada de todas as dependências complicadas que os aplicativos corporativos normalmente têm ao fatorar interações com esses sistemas nas interfaces, a linguagem usada na camada de domínio real acaba se tornando bastante concisa, óbvia e legível.
Considerando a forma em que eu vi a maioria dos softwares corporativos, na prática, o DDD pode parecer uma bala de prata, porque a maioria dos softwares corporativos tem uma separação tão pobre de preocupações que é quase impossível de ser testada, e a equipe de software vive com muito medo de mudar porque eles não têm idéia de quais podem ser os efeitos colaterais de alterações aparentemente triviais no código, enquanto uma camada de domínio adequadamente fatorada será testada e verificável independentemente. Mas, na verdade, o DDD reconhece que os sistemas raramente existem isolados. O DDD inclui padrões de enfrentamento para sistemas legados (camada anticorrupção, contextos limitados, para citar alguns).
Se você pratica o design orientado a objetos, incluindo a disciplina do acoplamento flexível, pratica o teste de unidade de maneira bastante religiosa e refata o código sem piedade, e trabalha com especialistas em domínio ao criar seu sistema, basicamente você terá um resultado basicamente sobre o que os defensores do design orientado por domínio estão falando.
Existem alguns padrões específicos descritos no livro de Evans que se aplicam principalmente ao desenvolvimento de software corporativo e alguns que são princípios bastante universais, mas essencialmente, o DDD é uma abordagem pragmática do desenvolvimento de software que pode, com o tempo, reduzir o acúmulo de dívida técnica, e torne seus clientes mais felizes porque você consegue falar o mesmo idioma entre si e fornecer soluções que funcionem melhor devido às vantagens de se entender melhor.
Uma descrição de alto nível pode ser -
Modele suas classes para espelhar as estruturas de dados e o comportamento do domínio do seu problema.
Isso permite que você mapeie as alterações no domínio do problema diretamente para as alterações no seu código; portanto, deve ser mais fácil atualizar à medida que o domínio do problema evolui.
AVISO LEGAL: Adicionei esta resposta depois que esta pergunta foi marcada como duplicada. Eu discordo, mas aqui estamos nós. :-)
O Design Orientado a Domínio visa projetar software em domínios de alto valor / alta complexidade.
Isso se transforma em uma abordagem diferente para a criação de software corporativo: há muito aprendizado envolvido e a consequência mais importante é que você não encontrará a solução certa à primeira vista.
Ou a combinação de ambos.
Nos dois sentidos, você precisará de boas bases de software para reescrever software com freqüência . Essa é a razão pela qual o livro enfatizou um determinado conjunto de padrões em torno do padrão do Modelo de Domínio: eles eram a combinação mais razoável em 2004.
No entanto, OOP e o padrão tático não são a coisa mais importante. O domínio técnico é necessário para criar um ótimo software de maneira evolutiva. Mas é apenas um ingrediente da receita. Os outros?