Há duas afirmações recorrentes associadas a DDD: 1) é mais recomendável para o desenvolvimento de sistemas com domínios mais complexos e; 2) deve começar pela explicitação da linguagem onipresente do domínio.
Um sistema CRUD não precisa de DDD! Qualquer tentativa de adotar práticas e padrões de DDD em sistemas CRUD acaba conduzindo a complexidades desnecessárias e difíceis de justificar. Afinal, complexidade é custo. Por sorte, [tweet]a maioria dos sistemas é feita como CRUD por opção de quem desenvolve e não pelas demandas do domínio.[/tweet]
Defendemos que a linguagem de domínio deve ajudar a explicitar as motivações para mudanças de estado das entidades. Logo, parece natural que a linguagem de domínio surja naturalmente no planejamento e na prototipação da experiência dos usuários para mudar esses estados.
Temos observado que a elaboração de protótipos de experiência (interface e usabilidade) são excelentes ferramentas para explicitação da linguagem onipresente. Aliás, de forma muito mais eficiente do que discussões que levam a descrições e glossários.
“Atiramos uma pedra na janela e ela quebrou”. Quem quebrou? A pedra ou a janela?
É fato que a língua portuguesa, por mais rica que seja, nos leva a construções de frases que são inevitavelmente ambíguas. Sobre quem escreve, sobre quem lê.
O esforço para construção de descrições puramente textuais é quase sempre ineficiente. Na maioria das vezes por pura falta de competência de quem escreve. Outras vezes, pela insuficiência da língua.
Começar um sistema fazendo protótipos de experiência (interfaces e usabilidade) é meio eficiente de colocar gente técnica e gente de negócios interagindo com meios que, de fato, ambos entendem. No fim, toda nova tela prototipada acaba se convertendo em, pelo menos, um método de entidade ou em um serviço.
Prototipar telas também é um meio barato para evitar enganos. Ajuda usuários a “enxergar” a necessidade de features que não havia considerado. Também ajuda os desenvolvedores a “cortar” recursos que pareciam úteis mas que não despertaram as reações esperadas (Lembre-se que recurso sem valor percebido pelo cliente é custo)
Por fim, é bom observar que se você não consegue imaginar uma experiência para seu usuário mais rica que um CRUD, então, você também não precisa investir tempo em tentar adaptar DDD a sua solução – a complexidade dela não justifica.
Não é necessário “inventar” artefatos para a linguagem onipresente. Ela precisa estar estar ali, viva, nas experiências que seu sistema proporciona. Por isso, comece por elas.
