Por onde começar ao fazer um modelo de domínio?

Question

Digamos que fiz uma lista de conceitos que usarei para desenhar meu modelo de domínio. Além disso, tenho alguns casos de uso dos quais fiz alguns diagramas de sequência do sistema.

Ao desenhar o modelo de domínio, nunca sei por onde começar:

1. Projetar o modelo como eu acredito que o sistema seja. Este é que, se estou modelando um corpo humano, começo adicionando os conceitos de classe de coração, cérebro, entranhas, estômago, olhos, cabeça, etc.
2. Comece projetando o que os casos de uso precisam ser feitos. Este é, se eu tiver um caso de uso que trata de fazer o corpo humano engolir algo, primeiro desenharia os conceitos de classe para a boca, garganta, estômago, entranhas, etc.

A ordem em que faço as coisas é irrelevante? Eu diria que provavelmente seria melhor tentar projetar a partir dos conceitos de casos de uso, pois geralmente são o que você deseja trabalhar, não outros tipos de conceitos que, embora ajudem a descrever bem todo o sistema, a maior parte do tempo pode Nem mesmo ser necessário para o projeto atual. Existe alguma outra abordagem que não estou adotando aqui? Como você geralmente aborda isso?

Obrigado

Answer 1

Eu começaria por um diagrama de classe com todos os relacionamentos e implementava apenas as classes necessárias de acordo com os requisitos do seu aplicativo.

Você pode usar uma abordagem anêmica (atributos mais getters e setters) para simplificar as coisas e evitar a etapa de escrever lógica de negócios na mesma etapa. Com um modelo anêmico, a lógica entraria em uma classe de serviço correspondente. Dessa forma, você pode considerar os casos de uso posteriormente.

Sei que algumas pessoas não apreciam essa maneira de fazer as coisas, mas isso ajuda na manutenção e evita alguns problemas de dependência.

Resposta à pergunta devorada de Elysium abaixo:

Em termos de análise, começando com casos de uso (o quê) e depois prosseguindo para o diagrama de classe (como) soa como uma boa regra geral. Pessoalmente, eu faria o diagrama de sequência (quando e quem?) Depois, como você precisa saber entre quais processos/objetos as mensagens precisam ser enviadas.

Além disso, minha opinião sobre as coisas é que a UML é simplesmente uma maneira de modelar um sistema/projeto e não uma metodologia por si só (diferentemente de Merise, Rad, Rup, Scrum etc.). Não há nada que pare de alguém começar com qualquer diagrama, desde que tenha informações suficientes para concluí -las. De fato, eles devem ser feitos simultaneamente, pois cada um dos diagramas é uma perspectiva diferente do mesmo sistema/projeto.

Então, apesar de tudo, depende de como você realiza a análise. Durante meus estudos, aprendi a abordagem rígida em cascata, onde você faz uma análise completa do início ao fim antes de produzir algum código. No entanto, as coisas podem ser diferentes na prática, pois o imperativo pode ser produzir uma aplicação de trabalho no menor tempo possível.

Por exemplo, fui apresentado à metodologia Scrum recentemente para um exercício envolvendo a criação de um site onde as pessoas podem publicar suas ficções. Como havia uma restrição de tempo e uma visão clara do que deveria ser alcançado, começamos imediatamente com um diagrama de classe nos ossos para representar o modelo de domínio. Os casos de uso foram deduzidos de uma série de telas simuladas que produzimos.

Da memória, as aulas eram histórias, capítulo, usuário e categoria. Esta última aula foi eliminada em favor de uma classe de tags mais flexível. Como você imagina, o diagrama completo de classes do projeto existente seria muito mais complexo devido à aplicação do design orientado ao domínio e às especificidades da linguagem de programação Java.

Essa abordagem pode ser vista como desleixada. No entanto, um site como esse poderia ser facilmente feito em algumas semanas usando um processo iterativo e ainda é bem projetado. A vantagem que um processo iterativo tem sobre a abordagem em cascata é que você pode ajustar continuamente os requisitos à medida que avança. A mudança de requisitos frequentes é uma realidade, pois as pessoas geralmente mudam de idéia e a possibilidade de produzir um aplicativo de trabalho após cada iteração permite que se mantenha no caminho para falar.

Obviamente, quando você está apresentando um projeto a um cliente, uma análise completa com diagramas UML e algumas telas simuladas seriam preferíveis, para que tenham uma idéia do que você está oferecendo. É aqui que entra o UML. Depois de explicar algumas das convenções visuais, um indivíduo deve ser capaz de entender os diagramas.

Para terminar, se você está na situação em que está tentando determinar o que um cliente deseja, provavelmente é uma boa ideia criar gradualmente um questionário que você pode trazer com você. Entrevistar uma pessoa é a única maneira de determinar quais conceitos/recursos são realmente necessários para um aplicativo, e você deve esperar voltar para esclarecer certos aspectos. Outra dica seria fazer uma pesquisa rápida na web quando você estiver confrontado com um assunto com o qual você não conhece.

No seu exemplo, isso seria passar pelo básico da anatomia. Entre outras coisas, isso ajudará você a decidir o que o modelo deve conter e que granularidade ele deveria ter (que grupo de órgãos deve ser considerado? Quão preciso ele precisa ser? Apenas os órgãos precisam ser modelados ou devem ser decompostos em seus constituintes como tecidos, células, composição química, etc.?).

Answer 2

Seja DDD, ou não, eu recomendaria para determinar a linguagem onipresente (UL), entrevistando o (s) proprietário (s) do produto. Estabelecer a comunicação de uma maneira que você e os proprietários de produtos falem o mesmo idioma não apenas auxiliares na comunicação, mas também poder discutir o projeto em termos comuns tende a ajudar o modelo de domínio a se definir.

Então, minha resposta é basicamente discutir, ouvir e aprender. O software atende a uma necessidade. Compreender o modelo do ponto de vista dos especialistas estabelecerá as bases sólidas para a aplicação.

Answer 3

Eu acho que o lugar para começar seria o que parece lógico e confortável. Provavelmente é melhor começar com os casos de uso, pois eles oferecem orientação e objetivos claros e ajudam a evitar situações de Yagni. Dado que você deve tentar desenvolver um modelo de domínio forte, ele realmente não deve importar, pois toda a imagem do domínio é importante.

Answer 4

Gostaria de compartilhar minha experiência para esse tipo de situação. Normalmente começo com testes e código de escrita. E tente cobrir uma caixa de uso final a ponta. Isso me dá uma ideia justa o suficiente sobre o problema e, no final, também tenho algo trabalhando comigo, que posso mostrar ao meu cliente. Na maioria das vezes, as histórias subsequentes se baseiam no topo da anterior, mas também acontece que as histórias subsequentes exigem mudanças no modelo anterior que eu criei. Mas isso não me afeta, pois eu já tenho uma boa cobertura de teste. Dessa forma, criei o modelo que se encaixa no problema atual, não no modelo que mapeia o mundo real.

Answer 5

Você começa com os requisitos de negócios que podem ser formalizados ou não. Se formalizado, você usaria diagramas de casos de uso.

Por exemplo, aqui estão os diagramas de casos de uso para um aplicativo de comércio eletrônico:http://askuml.com/blog/e-commerce/

http://askuml.com/files/2010/07/e-commerce-use-se-case.jpg http://askuml.com/files/2010/07/e-commerce-use-se2b.jpg

A partir desses casos de uso, você pode deduzir naturalmente as entidades comerciais: produto, categoria de produto, carrinho de compras, ... que é começar a preparar diagramas de classe.

Esta é uma prática recomendada em muitas metodologias, mas também é apenas senso comum e natural.

Answer 6

Resposta curta

Escolha um caso de uso, desenhe algum diagrama de colaboração (e um diagrama de classe) para realizar os objetos de domínio envolvidos. Concentre -se apenas nesses objetos participou para atingir a meta do caso de uso. Escreva o caso de teste TDD para definir a expectativa e modelar gradualmente suas classes de domínio para atender às expectativas. Tdd é muito útil para entender os comportamentos esperados e ajuda a obter o modelo de domínio mais limpo. Você verá seu domínio evoluir gradualmente junto com as expectativas do TDD.

Resposta longa

Minha experiência pessoal com o DDD não foi fácil. Isso foi porque não tínhamos fundações necessárias em primeiro lugar. Nossa equipe tinha muitos pontos fracos em diferentes áreas; Os requisitos não foram capturados corretamente e tínhamos apenas um representante de clientes que não foi realmente útil (não envolvido). Não tínhamos um plano de liberação adequado e os desenvolvedores tinham falta de conceitos orientados a objetos, melhores princípios e assim por diante. O principal problema que tivemos foi gastar muito tempo tentando entender a lógica do domínio. Nós esboçamos muitos diagramas de classes e nunca conseguimos o modelo de domínio certo, então paramos de fazer isso e descobrimos o que deu errado. O problema era que tentamos muito entender a lógica do domínio e, em vez de nos comunicarmos, fizemos suposições nos requisitos. Decidimos mudar nossa abordagem, aplicamos o TDD, começamos a escrever o comportamento esperado e codificamos o modelo de domínio para atender às expectativas do TDD. Às vezes, ficamos presos ao escrever casos de teste de TDD porque não entendemos o domínio. Conversamos imediatamente com o representante do cliente e tentamos obter mais informações. Mudamos nossa estratégia de liberação; Metodologia ágil aplicada e liberação com frequência para obter feedback real do usuário final. No entanto, necessário para garantir que a expectativa do usuário final fosse definida no nível certo. Refatoramos com base no feedback e, dessa forma, o modelo de domínio evoluiu gradualmente. Posteriormente, aplicamos padrões de design para melhorar a reutilização e a manutenção. Meu argumento aqui é que o DDD sozinho não pode sobreviver, temos que construir o ecossistema que abraça o domínio, os desenvolvedores devem ter fortes conceitos de OOP e devem apreciar o TDD e o teste de unidade. Eu diria que o DDD está no topo de todas as técnicas e práticas de OOP.