| Seu projeto tem uma pontuação total de 7 pontos ou mais? | ||
|---|---|---|
| Se seu projeto | Pontos | Concepções de suporte |
| Se sua aplicação for completamente centrada em dados e se qualificar verdadeiramente para uma solução CRUD pura, em que cada operação é basicamente uma consulta simples de banco de dados para criar, ler, atualizar ou excluir, você não precisa do DDD. Sua equipe só precisa colocar um rosto bonito em um editor de tabelas de banco de dados. Em outras palavras, se você puder confiar no fato de que os usuários irão inserir os dados diretamente em uma tabela, atualizá-los e, às vezes, excluí-los, você nem mesmo precisará de uma interface do usuário. Isso não é realista, mas é conceitualmente rele- vante. Se pudesse usar uma ferramenta simples de desenvol- vimento de banco de dados para criar uma solução, você não desperdiçaria o tempo e dinheiro de sua empresa no DDD. |
0 | Isso parece óbvio, mas normalmente não é fácil determinar simples versus complexo. Não é como se todas as aplicações que não são CRUD puras merecem o tempo e o esforço do uso do DDD. Assim, talvez possamos sugerir outros indicadores para nos ajudar a traçar uma linha entre o que é complexo e o que não é ... |
| Se seu sistema exigir apenas 30 ou menos operações de negócio, ele provavelmente é bem simples. Isso significaria que a aplicação não teria um total de mais de 30 histórias de usuário ou fluxos de caso de uso, com cada um desses fluxos tendo apenas uma lógica mínima de negócio. Se você puder desenvolver rápida e facilmente esse tipo de aplicação usando o Ruby on Rails ou o Groovy and Grails e não se importar com a falta de poder e controle em relação à complexidade e alteração, o sistema provavelmente não precisará usar o DDD. |
1 | Para ser claro, estou falando de 25 a 30 únicos métodos de negócio, não de 25 a 30 interfaces de serviço comple- tas, cada uma com vários métodos. O último pode ser complexo. |
| Assim, digamos que, em algum lugar no intervalo entre 30 e 40 histórias de usuário ou fluxos de caso de uso, a comple- xidade poderia ser pior. Seu sistema pode estar entrando no território do DDD. |
2 | O risco é do comprador: Bem frequentemente a complexi- dade não é reconhecida rapidamente. Nós, desenvolvedores de software, somos realmente muito bons para subestimar a complexidade e o nível de esforços. Só porque talvez queiramos codificar uma aplicação no Rails ou Grails não significa que devemos. No longo prazo, essas aplicações poderiam prejudicar mais do que ajudar. |
| Mesmo que a aplicação não seja complexa agora, a comp exi- dade dela aumentará? Você só pode saber isso ao certo depois que os usuários reais começam a trabalhar com ela, mas há um passo na coluna "Pensamentos de suporte" que pode ajudar a revelar a situação real. Tenha cuidado aqui. Se houver absolutamente qualquer indício de que a aplicação tem complexidade mesmo moderada — este é um bom momento para ser paranoico —, isso pode ser uma indicação suficiente de que ela na verdade será mais do que noderadamente complexa. Incline-se em direção ao DDD. |
3 | Aqui vale a pena analisar os cenários de uso mais complexos com especialistas em domínio e ver aonde eles levam. Os especialistas em domínio ... 1... . já estão solicitando recursos mais complexos? Se sim, isso provavelmente é uma indicação de que a aplicação já é ou em breve se tornará excessivamente complexa para usar uma abordagem CRUD. 2....estão entediado com os recursos ao ponto em que dificilmente vale a pena discuti-los? Provavelmente não é complexa |
| Os recursos da aplicação serão alterados com requencla longo de alguns anos, e você não pode antecipar que as altera- cões serão simples. |
4 | O DDD pode ajudá-lo a gerenciar a complexi a e a refatoraçãode seu modelo ao longo do tempo. |
| Você não entende o Domínio (2) porque ele é novo. a medida em que você e sua equipe sabem, ninguém fez isso antes. Isso provavelmente significa que ele é complexo ou, pelo menos, merece a devida diligência com análise analítica *ra. determinar o nível de complexidade. |
5 | Você precisará trabalhar com especialistas em domínio e testar os modelos para fazer a coisa certa. Você certamente também pontuou em um ou mais dos critérios anteriores, portanto, use o DDD. |