Consegui evitar os VOs e BOs ?

juzepeleteiro wrote:Qual o seu nome completo? Só para evitar que eu injustamente não contrate mais nenhum Ronildo na minha vida.

fiz algo de errado

?

ronildobraga wrote:

juzepeleteiro wrote:Qual o seu nome completo? Só para evitar que eu injustamente não contrate mais nenhum Ronildo na minha vida.

fiz algo de errado ?

Eu confundio você com o sergiotaborda no ultimo post. Foi mal, já alterei o post original.

juzepeleteiro wrote:

ronildobraga wrote:

juzepeleteiro wrote:Qual o seu nome completo? Só para evitar que eu injustamente não contrate mais nenhum Ronildo na minha vida.

fiz algo de errado ?

Eu confundio você com o sergiotaborda no ultimo post. Foi mal, já alterei o post original.

Nao quis dizer se o codigo esta errado, queria saber fiz alguma coisa de errado.

Virtual Machine Man Membro desde: 27/04/2005 18:52:49 Mensagens: 822 Offline

ele queria ter dado uma alfinetada no outro maluco, só que trocou os nomes.

auhauhah, mas to rindo até agora huahuahuh

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3196 Offline

juzepeleteiro wrote:Me retratando: Eu confundi o sergiotaborda com o ronildo no ultimo post. Foi mal Ronildo.

Sergio Taborda, nome anotado.

Era:
Qual o seu nome completo? Só para evitar que eu injustamente não contrate mais nenhum Ronildo na minha vida.

Com uma frase vc justificou tudo o que eu disse. Obrigado.

http://pt.wikipedia.org/wiki/Argumentum_ad_hominem

Forum Spammer Membro desde: 11/02/2005 08:08:02 Mensagens: 1511 Offline

Mas pra que o TO?

eu faria assim:

Enfim... o exemplo não ficou bom, mas não vi necessidade no TO.

Abraços!

Forum Spammer Membro desde: 11/02/2005 08:08:02 Mensagens: 1511 Offline

Segue um exemplo melhorzinho:

Alguns métodos do Service:

Uma entidade:

Um pouco de repositorio:

Só faltou o VO (Value Object), só que até agora não lidei com ele ainda. Por isso não tinha um exemplo fácil para colocar aqui.

Até +

Thiago Senna wrote:Mas pra que o TO?

...este é um daqueles exemplos super-simples; pequeno o bastante para ser irreal, mas o suficiente, espero, para que se possa visualizar o que está ocorrendo...

Portanto o meu exemplo nao é real, no caso eu estava demosntrando um servico do tipo CRUD. Logico que existe outros tipos de servicos e para isso vc demontrou um ótimo exemplo.

So corrigindo um detalhe no seu exemplo:

Thiago Senna wrote:
class UserService{ public Person saveUser(Person person){ Login login = new Login(); login.setName(person.getName()); login.save(); return person; } }

Porem eu espero que o que vc definiu ali como Person nao seja de fato uma entidade do dominio, pois as entidades do dominio são acessadas somente pelo dominio, se vc obrigar o servico a receber um argumento que seja uma entidade do dominio vc deve presupor que o servlet deve intanciar uma entidade do dominio para acessar o servico, e isso nao é correto com as regras do DDD pois o servlet nao faz parte do dominio para instanciar uma entidade do dominio

Objetos de Valor são classes auxiliares que agrupam muitos campos, como endereço, por exemplo
Portanto os VO sao inevitaveis, talves seja errado chamar isso de VO, TO, pois devemos seguir as nomeclaturas, mas é importante saber que esse objeto esta assumindo um papel semelhante quando era trafegado o TO entre as camadas
Se nos prestarmos atencao, veremos que o que vc definiu como person é na verdade um VO

Rafaelprp wrote:ele queria ter dado uma alfinetada no outro maluco, só que trocou os nomes.

auhauhah, mas to rindo até agora huahuahuh

eu so estou rindo agora. É engraçado como nao percebemos coisas tao obvias depois de muita discussão, lendo novamente o post, na verdade ela estava elogiando o Sergio.

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 347 Offline

Meio tarde mas,

Acho que vc ainda ta confundindo o que é um objeto anemico que o Shoes se referiu! Ou eu estou me confundindo!

ronildobraga wrote:
//Como eu gravava um objeto em um modelo anemico private void anemic(){ PessoaBO pessoaBO = new PessoaBO(); Pessoa pessoa = new Pessoa(); pessoa.setIdade(30); pessoaBO.save(pessoa); } //Como eu deveria gravar um objeto usando DDD private void DDD(){ Pessoa pessoa = new Pessoa(); pessoa.setIdade(20); pessoa.save(); }

Com o metodo acima me parece que vc ve o objeto Pessoa como anemico só por ele precisar do PessoaBO para se salvar. Isso não é la bem verdade pois essa é a separação que fazemos com o padrão repositorio!

Moral da história:

Um modelo é dito anemico quando eu tenho uma classe de dados e uma outra casse para manipular esses dados!

Um modelo é dito bem nutrido quando eu tenho uma classe que possui dados e ela mesmo manipula esses dados!

Ao meu ver é isso!

Espero ter ajudado ou se eu estiver errado alguem me corrija!

[]s

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3196 Offline

Primeiro é preciso deixar claro que VO (Value Object : Objecto de Valor) não é um TO. Exemplos de VO são : Adress , CPNJ , Range , Money , quase todas as classes principais da biblioteca TimeAndMoney e da Joda Time. São objetos com estado e opeações sobre esse estado. São muito uteis e normalmente podem ser usados para muitos fins. O que os distingue das entidades é que não têm chave e como tal podem ser usados em muitas funções.
Os VO são normalmente campos das entidades que visam simplificar operações do dominio. Outra caracteristica comum dos VO é que são imutáveis. Java tem alguns VO genericos como String , Integer e todos os Number e Date.

Por outro lado, TO não têm chave e além disso não são VO, ou seja, eles são puramente agregadores de dados que visam diminuir a quantidade de parametros de métodos e podem atravessar diferentes andares (tiers) da aplicação por serem serializáveis. Contudo, isto não significa que são sempre necessários. Uma simples string ou um int podem fazer esse papel.

Dito isto, no seu exemplo abaixo LogonTO tem chave. Isso é uma contradição. Se tem chave é uma entidade. Se é um TO não tem chave.

Não ha verdadeira necessidade de usar get/set num TO já que como ele não contém nenhuma lógica , não teriamos o que escrever nesses métodos e portanto não ha necessidade de encapsulamento. Mas isto é um detalhe. No final das contas os get/set nem pesam na JVM, então melhor usá-los por padrão. O ponto aqui é só chamar a atenção que devido ao objetivo do TO não precisamos deles.

Uma coisa que achei estranho é o repositorio ter um metodo para salvar dois argumentos ao mesmo tempo. Eu estava pensando que o uso do repositorio deveria ser

Pois reutiliza o mesmo método.

Eu não entendi muito bem o objetivo do seu serviço (é logar a pessoa, registrar o login da pessoa, ou os dois ?) mas ... suponho que se está criando um login para a pessoa. Eis como eu faria:

class UserService {

public void createLoginFor (String username, byte[] password) {
        // estou pedindo dados em bruto pq este´e um serviço do dominio
        // será chamado pelo servlet facilmente sem definir TO
       
        Person p = Repositoy.find(Person.class, username); // username é unico, então atua como chave

if (p==null) { 
            // essa pessoa não existe
            throw new PersonNotFoundException(username);
        }

PersonLogin login = PersonLogin.valueFor (p); 
        login.setPassword(password);

Repositoy.store(login);
 }

// outro serviço com os mesmos parametros.
 // serve para mostrar que quem sabe o que fazer com os parametros é o serviço (o método) 
 public void autenticate (String username , byte[] password ) {

Person p = Repositoy.find(Person.class, username); // username é unico, então atua como chave

if (p==null) { 
            // essa pessoa não existe
            throw new IncorrectUserCredentialsException(username);
        }

PersonLogin login = PersonLogin.valueFor (p);

if (!login.accept(password)){
             throw new IncorrectUserCredentialsException(username);
        }

// se está tudo ok, continua. não precisa retornar nada.
 }
}

@Entity  // o uso desta anotação , introduzido pelo Thiago Senna é uma
 boa, mas eu não usaria a anotação de JPA (persistencia) e sim uma 
anotação puramente de dominio. Mas isso ai é gosto e implementação, 
por agora entenda-se que @Entity significa 
apenas "isto é um entidade de dominio"
class PersonLogin {

private Key key;   // Key é um VO
   private Person p
   private byte[] password;

public PersonLogin valueFor (Person p) {
        PersonLogin  login =  Repository,find ( PersonLogin.class, p.getUsername())

if (login == null){
          login = new PersonLogin (p , new byte[0]);
      }
       
return login;
   }

private PersonLogin (Person p, byte[] password){
       // atribuções 
   }

public boolean accept( byte[] password) {
    return Arrays.equals(this.password, password);
 }

}

A seguir o codigo a que se refere este post.

ronildobraga wrote:So retratando um exemplo rapido para corrigir o primeiro exemplo que eu postei
//Meu servlet ou algo do genero public class Beta { private void usandoDDDCorretamente(){ LogonTO to = new LogonTO(); to.setName("fulano"); to.setKey(1); to = new UserService().saveUser(to); System.out.println(to.getName()); } } //Servico do dominio, contem a logica de negocio do dominio class UserService{ public LogonTO saveUser(LogonTO to){ LoginEntity login = new LoginEntity(); PersonEntity person = new PersonEntity(); login.setName(to.getName()); person.setKey(to.getKey()); Repositorio.save(login, person); return new LogonTO("fulano gravado com sucesso", to.getKey()); } } //Meio de como persistir os dados do dominio class Repositorio{ public static void save(LoginEntity login, PersonEntity person){ System.out.println("gravando: " + login.getName() + " chave: " + person.getKey() ); } }

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3196 Offline

brunohansen wrote:
(...)

Com o metodo acima me parece que vc ve o objeto Pessoa como anemico só por ele precisar do PessoaBO para se salvar. Isso não é la bem verdade pois essa é a separação que fazemos com o padrão repositorio!

Eu concordo consigo. Realmente "save" é um método do repositorio.

Moral da história:

Um modelo é dito anemico quando eu tenho uma classe de dados e uma outra casse para manipular esses dados!
(...)

É isso mesmo. No seu exemplo da idade é otimo para demonstrar DDD , se fizermos algumas alterações ...

O atributo permite à classe calcular a idade (em qq data) , compara pessoas pela idade e sabe se a pessoa era nascida numa certa data.
Este monte de métodos é só para mostrar o que se pode fazer, mas a escolha de implementar estes métodos deve vir do dominio. Ou seja,
se o dominio exige que comparemos pessoas com base na idade é bom que pessoa permita isso, mas se o dominio não exige isso, não precisa implementar. A ideia é que ao logo do tempo, a classe Person ganhe a funcionadliade necessárias ao dominio.

Um comentário sobre a classes de manipulação de datas. Estas classes por si mesmas representam um dominio (Tempos e Data) e bibliotecas como a Joda Time tentam implementar esse dominio. Só que o fazem usando apenas VO e não entidades. Afinal é estranho dar uma chave para uma data. Estou dizendo isto só para mostrar que um dominio pode usar classes do outro dominio de forma directa se elas forem VO. As lógicas contidas nos metodos da classes da data são coesas para o seu dominio, o que permite o dominio superior muito mais flexibilidade e nenhuma preocupação com a logica interna dos métodos (SoC : Separation of Concerns - Separação de Responsabilidade)
(As classes que usei nos exemplos são meramente ilustrativas e não são o uso de nenhuma biblioteca)

sergiotaborda wrote:
Eu não entendi muito bem o objetivo do seu serviço (é logar a pessoa, registrar o login da pessoa, ou os dois ?) mas ... suponho que se está criando um login para a pessoa.

rsrsrs e realmente nao era pra ser entendido, pois eu disse:
Eu adicionei uma logica bem simples ao servico so para entender que la existe uma logica, seja ela qual for

Portanto eu nem pensei que logica era essa, acho que errei em demonstrar dessa forma, parabens por demonstrar uma logica mais interessante e mais proxima do real sem cair em muita complexidade.

Com as agumentacoes do brunohansen acho que ficou bem claro o que é um modelo anemico, e os exemplos agora retratam algo mais proximo do mundo real.

Forum Spammer Membro desde: 11/02/2005 08:08:02 Mensagens: 1511 Offline

ronildobraga wrote: Porem eu espero que o que vc definiu ali como Person nao seja de fato uma entidade do dominio, pois as entidades do dominio são acessadas somente pelo dominio, se vc obrigar o servico a receber um argumento que seja uma entidade do dominio vc deve presupor que o servlet deve intanciar uma entidade do dominio para acessar o servico, e isso nao é correto com as regras do DDD pois o servlet nao faz parte do dominio para instanciar uma entidade do dominio.

Então.. no meu exemplo o Person é uma entidade. Não vejo problemas caso o controle conheça as classes de domínio. Ao meu ver o que não seria certo era o domínio conhecer camadas acima dele (classes que são da view ou controle).

Quanto aos VO's acho que os exemplos do Sergio ficaram ótmos.

Thiago Senna wrote:

ronildobraga wrote: Porem eu espero que o que vc definiu ali como Person nao seja de fato uma entidade do dominio, pois as entidades do dominio são acessadas somente pelo dominio, se vc obrigar o servico a receber um argumento que seja uma entidade do dominio vc deve presupor que o servlet deve intanciar uma entidade do dominio para acessar o servico, e isso nao é correto com as regras do DDD pois o servlet nao faz parte do dominio para instanciar uma entidade do dominio.

Então.. no meu exemplo o Person é uma entidade. Não vejo problemas caso o controle conheça as classes de domínio. Ao meu ver o que não seria certo era o domínio conhecer camadas acima dele (classes que são da view ou controle).

Thiago, minhas afirmações são baseadas no que eu pude aprender com esses posts, porem por mais que esclarecemos algumas coisas, outras eu sinceramente não sei como resolver.

No final das contas eu não sei responder a sua pergunta

Eu estou lendo e traduzindo um material sobre DDD(nfoQ Book: Domain Driven Design Quickly), espero que ate segunda eu possa responder essa duvida.

Observações:
Eu tinha publicado a tradução no meu blog, mas acho que estou violando os direitos autorais.
Mesmo que ele seja free para download é necessário pagar uma taxa para impressão.

Notícias, artigos e o maior fórum brasileiro sobre Java