| Autor |
Mensagem |
|
|
Primeiro defina sua entidades:
Turma
Aluno
Disciplina
etc
Depois pense no mundo real para fazer as associações.
Uma turma possui alunos? Se sim coloque dentro dela a coleção de alunos. Uma Turma possui disciplinas? Hmmm, em minha opinião não diretamente. Quem possui Disciplina(s) deveria ser uma entidade Curso. Um Curso contém um grade de disciplinas e turmas relacionadas.. e por aí vai ...
|
 |
|
|
Concordo com você em relação à aplicação ser simples o suficiente pra não usar DDD. Mas numa aplicação complexa, onde já estamos usando DDD, deixar o CRUD fora do domain não seria bobagem?
Mas eu não me referi a aplicações simples, nem para aplicações que não usam DDD. Me referi a frameworks que lhe dão subsídios para que você não perca tempo com o arroz e feijão.
Você pode ter complexas aplicações modeladas em DDD e mesmo assim utilizar recursos prontos de terceiros que lhe dão produtividade e não impactam em sua modelagem. CRUD é CRUD, se alguém me oferece isso de graça, eu não quero gastar nenhuma linha de código para isso... SE precisar e QUANDO precisar especializar este processo, isso será feito sem impacto algum. Este processo pode ser simples ao Domínio, mas é muito rotineiro o que acaba impactando na produtividade.
Obviamente, caso não trabalhe com algum framework que ofereça estes serviços, a melhor saída é se manter com a própria modelagem... ou desenvolver seu próprio framework caseiro que cuide disso.
|
|
|
|
|
Siga a mesma lógica realizada para Aluno.
|
|
|
|
Mas aí caímos no Entity.insert() falado acima.
Não necessariamente. Um repository não faz apenas CRUD, eles realizam buscas necessárias para os entities. *Nestes e outros casos* um repository dentro de um entity faz todo sentido do mundo.
Outra situação é ocorrer em meio de um processamento de método de negócio, um objeto (um Aggregate) persistir outro objeto (composto pelo Aggregate), ou até mesmo requisitar sua própria persistencia. A grande diferença é o contrato de sua assinatura, ela não faz sentido ter um save ou persist. Mas se em meio a sua lógica for necessário guardar sua informação no repositorio, não te pq não faze-lo.
Normalmente, mas não por regra, os CRUDs acabam por cair nas costas de um Service.
|
|
|
|
|
Não existe mal em vc chamar Repositories de um Entity ou Service. Tanto um como outro são da camada de negócio, esta tudo ok.
|
|
|
|
feliperod wrote:
Lezinho wrote:Camada de visão e aplicação não é domínio, portanto de nada tem haver com DDD. Pode usar EntityManager, Session, SQL direto na página via JSTL ... Eu quando tenho CRUD simples sem intervenção do negócio não escrevo uma linha de código java, utilizo o DAO declarativo do Seam.
Mas tudo isso, de nada tem haver com DDD ... [2]
Isso não acaba gerando regras de negócio fora do domain? Acho que o domain é reponsável por tratar e resolver todo o problema do sistema, e o CRUD está incluso como problema do sistema.
Se vc preenche um formulário, clica no botão e os dados são persistidos e validados sem você precisar programar, não existe mal que isso fique em um framework (acredite, isso é possível com frameworks como o Jboss Seam). Não é preciso DDD para isso pois Domain Driven é para construir o Design do código, mas já que você não precisou codificar, portanto não precisou do design.
Se seu CRUD ficar mais complexo, então neste momento você constrói classes para isso com DDD... mas note que você não precisou disto no primeiro momento e pode ser que nao precise para o sistema inteiro. Programação incremental é uma ótima aliada a metodologias ágeis e não fere preceitos de design.
|
|
|
|
feliperod wrote:Acho que essa questão seria facilmente resolvido com o uso de um PessoaRepository.
A classe Pessoa deve conter regras do tipo que elas tem no mundo real. Disso consiste a abstração.
Por exemplo, Pessoa.pedirMercadoriaParaEstoque(String mercadoria). Já o codigo pertinente a salvar uma Pessoa ou não vai no PessoaRepository.
Mas aí fica uma outra dúvida, é bom chamar o repository direto da Action do Struts?
Cabe a decisão da equipe, contudo repository faz parte do negócio. Qualquer livro de DDD você vai ler a recomendação de isolar camada de negócio de camada de aplicação (Actions, ManagedBeans, etc), geralmente isso é o mais indicado.
|
|
|
|
spwe wrote:
- Deixar que o cliente de sua classe saiba de detalhes como "que posiçao do array esta determinado usuário". Isso não deve acontecer em hipótese alguma.
Como assim??
----------------------------------------------------------------------------------------------------------------
Obrigado pelas dicas
Essa classe seria uma regra de negocio??, pois pretendo criar um view de cadastros
e classes de persistencia, separando em camadas. Isto está correto ??
Você estava passando como parâmetro um numero que representava uma posição no array, para a deleção. Uma classe que representa uma "entidade", não deve depender de detalhes de infraestrura, como por exemplo posição de array. Passe o próprio objeto a ser deletado, como demonstrei.
|
|
|
|
|
Classes de negócio sao aquelas que contém características (atributos) e comportamentos (métodos) que se assemelham com um problema (ou representação) do mundo real, pertinente ao sistema. Se a classe Turma e Aluno possuem essas qualidades, então elas são classes de negócio.
|
|
|
|
Cara, sua pergunta esta com erro de concordância ou falta de pontuação, sei lá, não deu pra entender o que você quer. Bom, pelo menos deu pra entender algumas coisas que você anda fazendo de errado quando codifica:
- Utilize nome de classes no singular quando se refere a uma unidade. A classe "Aluno" representa uma unidade, não deve ser ter seu nome no plural ("Alunos"). Nomes de variáveis para collections tudo bem usar plural.
- Evite codificar com nomes de variáveis que não representam nada para quem le o código, como:
... "a" é um nome que não diz nada.
Imagine se este método tivesse mais algumas linhas de código, como saber o que é a varável "a": tendo que toda vez olhar a assinatura do método? Péssimo isso.
- Deixar que o cliente de sua classe saiba de detalhes como "que posiçao do array esta determinado usuário". Isso não deve acontecer em hipótese alguma.
Para alguém excluir um usuário da lista de turma, o mais natural é passar o Usuario (ok, para algumas implementações poderia ser enviado um identificador, como numero da matrícula, mas eu ainda prefiro enviar o próprio objeto usuário).
Portanto, seu drop seria melhor assim:
Para mostrar a turma com os alunos, faça:
|
|
|
|
Anotações são apenas informações jogadas ao vento, não são códigos.
No caso do JPA, sua classe continua sendo POJO se apenas for anotada, mas deixa de ser se você utilizar EntityManager dentro dela (por isso use a abstração oferecida por um Repository).
Uma classe anotada não muda de comportamento, não ganha novas características nem nada, quem infere isso são os manipuladores das anotações... esses sim não são POJOS.
Levar os jars legados é um fato. Mas nada que uma refatoração não resolva. O melhor de tudo, a refatoração vai ser muito simples e sem possibilidades de erros em execução, pois as anotações não atribuem comportamentos inesperados... tudo que vc for pegar de erro será em tempo de compilação (importações, etc).
Eu utilizo algumas Entities JPA como entidades do DDD sem dor na consciência. 
|
|
|
|
Por razões de performance, tente construir a coleção de Alunos com uma implementação de java.util.Set.
ArrayList é indexado, o que gera um certo custo, e nem sempre é necessário.
[]'s
|
|
|
|
ActiveRecord não é legal para o design de sua modelagem. Pense da seguinte forma, Fornecedores não se salvam nem se deletam.
Se você tenta modelar os objetos de forma que façam sentido para o negócio, os métodos das classes tem que fazer sentido também.
|
|
|
|
Thiago Senna wrote:Só depende do quão purista você é, rsrs..
Em outras palavras, depende o quanto chato você quer ser... hehe. Seja um cara legal com sua equipe, use anotações  .
|
|
|
|
Duplicar nem pensar... não existe motivos para isso, ainda mais se falando de POJOS.
Se a Entity JPA é POJO e seu Entity DDD é POJO, então os objetos são identicos.
Metadados são simplesmente metadados.
|
|
|
|