Pular para o conteúdo principal

Modelo de Domínio Rico e Anêmico








E aí, pessoal ?
Voltamos com mais uma postagem sobre projeto de sistemas.
Dessa vez, o assunto é sobre modelo anêmico e modelo rico. O que será isso, hein ?
Para ficar por dentro da discussão sugiro ouvir o Podcast 11: Modelo Anêmico e Rico no qual foi baseado esse post.

No podcast, de acordo com o Alexandre Valente, modelo anêmico é basicamente aquele modelo que tem as regras de negócio um pouco isoladas das entidades de domínio.  Já no modelo rico, as regras estão um pouco melhor distribuídas entre as entidades.

E por que será que dá tanto pano para a manga falar desse assunto ?
Porque, como a maioria das decisões de projeto, cada modelo há seu pró e contra. Vamos discutir um pouco sobre isso.

No podcast, o Alexandre Valente defendeu bastante o modelo anêmico, por ter tido boas experiências com ele e não tão boas assim com o outro. Para ele, a principal vantagem desse modelo é a produtividade. No entanto, para o Giovanni Bassi, esse modelo é um problema. Produtividade não é justificativa, já que, na sua opinião, ele poderia ser mais produtivo tendo um ambiente de desenvolvimento que segue o modelo rico. Para o Giovanni, o modelo anêmico é muito focado nos dados, o que torna as tarefas de teste muito mais difíceis. Já o modelo rico, é mais focado em comportamento e não em dados, sendo assim, mais fáceis de testar. Quanto maior o sistema, mais importante ter comportamento e não dados.

Após alguns prós e contras, quem vocês acham que ganha no quesito mercado ?
Foi o que eu pensei, o modelo anêmico!
Para uma pessoa começar no modelo rico, ela tem que entender bastante do negócio e da ideia da orientação a objetos. No mercado, não se muito tempo para isso, então as pessoas acabam debandando para o modelo anêmico, até sem perceber.

Toda essa discussão não quer dizer que o modelo anêmico é a maneira errada de programar e o modelo rico é o certo. Isso depende bastante da sua aplicação e do nível de maturidade/conhecimento da equipe. A ideia é manter o equilíbrio.

Até a próxima galera! :)

Comentários

Postagens mais visitadas deste blog

TDD e BDD

Olá pessoal, Hoje nós falaremos sobre TDD e BDD! Logo que eu ouvi sobre eles gerou um confusão enorme na minha cabeça. O que é TDD e BDD ? TDD – Test-Driven Development (Desenvolvimento Orientado a Testes) é o Desenvolvimento de Software orientado a Testes. O processo de desenvolvimento do TDD seria: Escrever um teste, sem mesmo ter escrito o código real a ser testado (Imagine o que deseja testar). Executar os testes e acompanhar a falha (Pode ser um código falso que retorne o  erro) Escrevemos a funcionalidade do sistema que iremos testar. Testar novamente, agora para passar (Se não passou algo saiu errado, faça novamente o passo 3) Refatore sua funcionalidade e a escreva por completo (o teste também) (Refactor) Passe para o próxima estória ou caso de uso e inicie novo teste. Confesso que isso é bem estranho, principalmente os passos 1 e 2 rs, até porque se funcionasse sem código seria mais estranho ainda kkk. BDD – Behavior Driven Dev

Padrões GRASP

Olá pessoal! Hoje nós vamos falar sobre os padrões GRASP. Engraçado né? Está no plural. Isso porque GRASP é um acrônomo para General Responsability Assignment Software Patterns ( Padrões Gerais para Atribuição de Responsabilidades). Bom, para esse post nós teremos como base esse minicurso do YouTube sobre   padrões GRASP . Vamos lá! Uma definição feita no minicurso sobre padrões GRASP é que: é um conjunto de princípios fundamentais para modelagem de objetos e atribuição de responsabilidades escrito na forma de padrões. Um padrão do GRASP é um par: problema e solução. Já que é um par problema solução, vamos falar primeiro o problema e depois o padrão mais adequado para a ocasião. 1) Qual princípio básico para se atribuir responsabilidade a objetos ? Ora, vamos atribuir a responsabilidade a quem tem a informação para realizá-la. Qual o padrão que estamos utilizando ? O information expert! Os benefícios ao usar são: Encapsulamento mantido  Comportamento é bem mais distribu

Medição de Software

Olá, hoje nós vamos falar sobre medição de software e da experiência em fazê-la no sistema para a escola de surfe que estou desenvolvendo na faculdade juntamente com outros colegas. Os conceitos aqui apresentados, se baseam na apostila de medição de software . Para começar, o que é medição de software ? Segundo Dumke, medição é o processo pelo qual números ou símbolos são atribuídos a propriedades de entidades do mundo real de forma a descrevê-las. Sendo assim, é possível perceber a importância da análise estatística do desenvolvimento do seu software, pois com ela consegue-se obter informações relevantes, tais como: tamanho do projeto, custos de desenvolvimento, quantidade de defeitos e etc. No contexto de projetos de software, a medição pode auxiliar a elaboração de planos realísticos e pode prover informações úteis ao acompanhamento do alcance dos objetivos, à identificação de problemas e à tomada de decisões informadas. No contexto organizacional, a medição pode auxiliar