Consegui evitar os VOs e BOs ?

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

J2Alex wrote:sergiotaborda,

O que você acha que há de errado na seguinte abordagem:

public class Conta { ... public void transferirPara(Conta conta, Double valor) { ... } .... }

Eu considero isso bem intuitivo e funcional...

Otimo. Então use. Não tenho nada contra isso.
O meu argumento é apenas :
1) Isso não mostra a necessidade dos objetos do tipo serviço que existem em DDD. E era esse o meu ponto.
2) Isso não funciona num sistema real de banco. (eu já tentei usar)
2.1.) Não funciona porque não é responsabilidade da conta fazer essa operação. É como usuário.autentica() : não é responsabilidade do usuário se autenticar, é o serviço de segurança que tem que fazer isso.

Mas , como disse, se funciona para si, use.
Me responda apenas:
1) quem vai invocar conta.transferePara(outra, valor) ?
2) E,porque não , outra.transfereDe(conta, valor) ?

sergiotaborda wrote:2) Isso não funciona num sistema real de banco. (eu já tentei usar)
2.1.) Não funciona porque não é responsabilidade da conta fazer essa operação. É como usuário.autentica() : não é responsabilidade do usuário se autenticar, é o serviço de segurança que tem que fazer isso.

Não, não considero que seja a mesma coisa que usuário.autentica().

conta.transfere(...) pra mim ter a ver com negócio, autenticação de usuário não.

Me explique melhor porque isso não funciona em um sistema real? Cite argumentos concretos que justifiquem isso, por favor.

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

J2Alex wrote:

sergiotaborda wrote:2) Isso não funciona num sistema real de banco. (eu já tentei usar)
2.1.) Não funciona porque não é responsabilidade da conta fazer essa operação. É como usuário.autentica() : não é responsabilidade do usuário se autenticar, é o serviço de segurança que tem que fazer isso.

Não, não considero que seja a mesma coisa que usuário.autentica().

conta.transfere(...) pra mim ter a ver com negócio, autenticação de usuário não.

Não estamos falando de negocio , estamos falando de dominio.
transfere é uma operação do mesmo dominio de conta, autentica é uma operação do mesmo dominio de usuário. autentica não é uma operação do dominio de conta.

Me explique melhor porque isso não funciona em um sistema real? Cite argumentos concretos que justifiquem isso, por favor.

Já expliquei, mas aqui vai de novo. Na realidade uma transferencia não é a alteração do saldo da conta , o qual não é um atributo da conta. Transferencia é a criação de pares de movimentos de conta. Eu preciso saber a conta para construir os movimentos, mas a conta são se altera. Os movimentos são necessários porque criam uma historia do uso da conta: o extrato. O extrato é o que o cliente vê. O saldo é uma função em cima dos movimentos/do extrato. Os movimentos podem ser de diferentes tipos (DOC,TED, interno, externo , etc...) e cada uma tem as suas regras , que nada têm a ver com as contas. Como disse a conta é um identificador que é usado pelo resto do sistema.
Para as funções de report vc não quer a conta, vc quer os movimentos.
Para as funções de contabilidade vc quer a contraparte dos movimentos e não a conta.

Em concreto: uma conta não tem um campo saldo, nem as operações setSaldo(), getSaldo(); Tem o método saldo() que consulta os movimentos (na realidade pode consultar um cache com o saldo, mas não pode alterá-lo). Também não têm as funções aumentaSaldo e diminuiSaldo.
Por outro lado, existem mais informações necessárias à transferencia, como quem a autorizou, quando e porquê.

Para vc como usuário de banco transferencia parece simples, mas para o banco não é. É coisa séria. Esta diferença de visão deve-se ao encapsulamento. O serviço pede apenas como parametros duas contas e um valor, mas o sistema tem muito mais coisas a criar a partir dai.

Eu dei o exemplo da transfrencia bancária porque é classico nestas situações em que um serviço é requerido. Mas sintam-se à vontade de implementar de outra forma.

P.S. Vc não respondeu Às perguntas:
1) quem vai invocar conta.transferePara(outra, valor) ?
2) E,porque não , outra.transfereDe(conta, valor) ?

sergiotaborda,

Responderei às suas questões assim que sair do trabalho. Hoje tá meio complicado aqui... rs.

sergiotaborda wrote:
Vc precisa de um terceiro "ser" que manipula os objetos do dominio

Portanto, quando a logica de negocio envolve mais um dominio, nos criamos entao um servico para este gerenciar estes dominios, e o servlet pode acessar diretamente esse serviço, pois ele faz parte do dominio

sergiotaborda wrote:
A "logica de negocio" está na realidade distribuida entre os objectos do dominio , cada uma coma a sua responsabilidade e não mais do que essa

Apesar de vc citar que a logica esta distribuida nos objetos de dominio, nos vimos que parte da logica na verdade esta no servico, porem como o servico faz parte do dominio vc pode dizer que a logica continua no dominio. Portanto digamos assim: Uma Pessoa(Objeto de dominio) pode conter um repositorio, porem quando a logica de negocio envolver outra dominio, sera necessario criar um servico que ira gerenciar os dominios e seus respectivos repositorios. correto ?

sergiotaborda wrote:
eu sei muito bem a diferença entre Façade e Serviço. Isso não é um problema para mim, e pelo visto para si tb não. Só que eu não quiz poluir a discussão com esse detalhe. Eu sei que ao fazer isso iriam dizer que afinal estaria usando objetos que não são do dominio (aka TO) para passar a informação , e voltariamos ao ponto inicial da conversa.
Como o objetivo é entender DDD e no caso, explicar que DDD incorpora a noção de serviço , além de entidade de objeto de valor.

Mas já que vc levantou a lebre .... DDD não vive isolado do mundo, e não é a palavra final em desenvolvimento de software. Para que DDD funcione, ou seja, para que haja um foco efetivo no dominio, tem que existir um infraestrutura que lhe dê suporte. Por exemplo, é chato conectar framewroks web com DDD sem alguém no meio que traduza os requests em chamadas ao serviço do dominio. A camada de aplicação é necessária mesmo com DDD. E é por isso que DDD é muita parra e pouca uva. O assunto era explicar como evitar TO e vc simplesmente acaba de mostrar que DDD não evita TO, aliás necessita deles para serem passados como parametros dos serviços.
Lamento Ronildo, eu não queria desapontá-lo antes do tempo, mas o eliziario não quiz brincar do mesmo jogo, então aqui fica a verdade. DDD não evita TO.

Realmente DDD nao evita o TO, pois precisamos passar parte dos objetos de dominio atraves de parametros para os servicos do dominio, porem isso so ocorre quando precisamos trabalhar com mais de um dominio, seja eles iquais ou diferentes.
O que eu nao entendi foi Façade e Serviço, o que isso tem haver ?

Porem eu estou com duvida em uma coisa: Servico realmente retrata a situação quando precisamos resolver a logica dentre 2 dominios ? Eu me pergunto isso pois no exemplo inicial vc usou um servico ele resolve a logica de um dominio especifico, por isso eu devo ter feito confusão achando que vc estaria fragmentando o dominio.

eliziario wrote:
Não vou nem comentar ainda a mistura de código de transação com código de negócios. Também é lamentável que em pleno 2007 ainda tenha gente que use controle de transação de maneira programática e não declarativa, isso realmente me dá muito desgosto.
Sinceramente, acho que você deveria ler o livro do Evans, e o Object Design da Wirfs-Brock. Depois de ler os dois, leia Refactorings do Fowler pra consertar esse seu código aí em cima.

É obvio que o exemplo nao retrata uma situção real, cito um trexo que ja citei aqui novamente
Para ajudar a tornar isso tudo mais concreto, eu usarei um exemplo funcional. Como todos os meus exemplos, 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 sem cair na complexidade de um exemplo real.

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

ronildobraga wrote:

sergiotaborda wrote:
Vc precisa de um terceiro "ser" que manipula os objetos do dominio

Portanto, quando a logica de negocio envolve mais um dominio, nos criamos entao um servico para este gerenciar estes dominios, e o servlet pode acessar diretamente esse serviço, pois ele faz parte do dominio

Não entendi de onde vc tirou a ideia de que ha mais do que um dominio no exemplo.
Dominio = Entidades + Objetos de Valor + Serviços
Sendo que a quantidade de cada um é variável.
Repositório é uma forma padronizada dos objetos do dominio se encontrarem entre si. (Na prática é uma forma de encapsular a persistencia, mas em teoria não é esse o seu objetivo principal, já que eu posso persistir coisas que não são do dominio e/ou não persistir coisas que uso no dominio)
O repositorio é por dominio.

Servlet não pertence ao dominio. Ele pertence à aplicação ou à intraestrutura ,dependendo das responsabilidades que ele tem.

"logica de negocio" e "logica de dominio" não necessáriamente são a mesma coisa. A logica de negocio é um conjunto de logicas de dominio.
Se a sua aplicação só tem um dominio, a logica de negocio é sobre um dominio. Mas, por exemplo, num ERP existem vários dominio (finaceiro, contábil, produção, estoque, etc... ), e uma só logica de negocio (a integração dos dominios para um determinado fim)

ronildobraga wrote:
(...)Portanto digamos assim: Uma Pessoa(Objeto de dominio) pode conter um repositorio, porem quando a logica de negocio envolver outra dominio, sera necessario criar um servico que ira gerenciar os dominios e seus respectivos repositorios. correto ?

Primeiro : Pessoa não contém um repositorio. Ela usa um repositorio.
Segundo: Se a logica de negocio envolve mais do que um dominio a aplicação é diferente. Exemplo: O dominio Contabilidade vê ContaContábil e o dominio Financeiro , ContaFinanceira , o dominio Contabilidade não vê Produto e o dominio de produção não vê ContaContábil.
Isto, se vc quer isolamento de dominio, que é o amago da questão. Estou supondo que vc quer, pois o objetivo do DDD é encapsular a logica de dominio de forma que elas sejam reutilizáveis. Já pelo reutilizáveis vc entende que ; como cada negocio tem a sua maneira de ser, ele usará os objectos do dominio de forma diferente, mas de forma muito semelhante a um outro negocio.

Voltemos então ao exemplo de um só dominio. Imagine o dominio como um circulo. Vc tem no centro do dominio as entidades. Elas pertencem apenas a um dominio e não mais do que um. As entidades encontram-se umas às outras por meio de um repositorio. Que fica dentro do circulo, sem tocar na fronteira. A fronteira do circulo é onde os serviços estão.
Então, todos os pedidos são enviados pelo exterior (a camada de aplicação) aos serviços. Os serviços usam as entidades e os objetos de valor para executar uma funcionalidade que as entidades por si mesmas não podem. No executar desta funcionalidade metodos das entidades e dos objetos de valor são usados. Esses métodos executam "mini-logicas" e podem delegar a outras entidades e/ou serviços certas funções.

Entenda que o dominio é apenas uma camada do sistema. Existem muitas outras.

Pensemos agora que vc precisa organizar funcionalidades de dois domínios. Aqui vc usaria outro tipo de desenvolvimento. Eventos/notificações (EDD), SOA ou BPM. Isso é outro assunto.

ronildobraga wrote:
Realmente DDD nao evita o TO, pois precisamos passar parte dos objetos de dominio atraves de parametros para os servicos do dominio, porem isso so ocorre quando precisamos trabalhar com mais de um dominio, seja eles iquais ou diferentes.
O que eu nao entendi foi Façade e Serviço, o que isso tem haver ?

Lembre-se que os objetos do dominio ficam dentro do dominio (dentro do circulo) eles são invisiveis a quem está fora do circulo.
Deste ponto de vista passar Pessoa como parametro para o serviço (ou conta, etc..) é uma violação desse principio, e por isso é errado usar Pessoa num servlet por exemplo. E por isso vc teria que usar um TO para compor os dados de pessoa necessários ao serviço.
Então, um serviço de dominio não tem como parametro os objetos do dominio, mas sim outros objetos utilitários (que chamarei de TO).

Então, o seu servlet lê um request. Algum framework, ou vc na mão, lê os dados do request e decide o que fazer com ele. transforma os dados do objeto request num objecto comestivel ao serviço que executará a funcionalidade necessária. O serviço recebe esse objeto burro e entende o que vc pretende dele. Ele invoca os objetos de dominio necessários e executa o processo. Se ele tiver que retornar alguma coisa , essa coisa tb será um TO, que a camada que chamou o service converterá para um response, que o servlet enviará ao browser.

Quanto à diferença entre façade e serviço , isso é assunto para outro topico. Mas, resumidamente , façade é uma condensação e encapsulação de execuções de serviços. (O objeto que vc usa é uma fachada dos objetos verdadeiros e/ou a funcionalidade que vc requesita é uma fachada para o requesito de várias outras funcionalidades )

ronildobraga wrote:
Porem eu estou com duvida em uma coisa: Servico realmente retrata a situação quando precisamos resolver a logica dentre 2 dominios ?
Eu me pergunto isso pois no exemplo inicial vc usou um servico ele resolve a logica de um dominio especifico, por isso eu devo ter feito confusão achando que vc estaria fragmentando o dominio.
...

Parece que vc está entendendo que CRUD é um dominio. Se é isso, não.
CRUD não é um dominio. No exemplo eu deixei o CRUD ser um serviço cujo objetivo é popular o repositorio de entidades de forma direta ( ou seja, sem logicas acopladas). Mas isso foi um exemplo.
Teoricamente nenhum crud deveria ter logicas acopaldas, mas sabemos bem que isso é mentira. Então a ideia é deixar o dominio validar e responder ao crud. Mas só isso não é suficiente e depende muito da aplicação. Num ERP , por exemplo , fazer crud interage com vários dominios e ai o CRUDService não faz sentido.

Moral da historia: Em boa verdade, CRUD é uma operação sobre o repositorio do dominio. Que tem que ser executada com a conivência do dominio (para validação por exemplo) mas cuja responsabilidade final não é do dominio per se mas sim da aplicação.

Não entendi direito. O Service neste caso poderia normalment eapenas estimular os objetos, ou seja em vez de:

Era exatamante isso que eu queria dizer, acho que não fui feliz na mensagem. Imaginei que seria mais fácil entender da forma que escrevi.

Valeu.

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

Daniel Quirino Oliveira wrote:

sergiotaborda wrote:
O ActiveRecord é um padrão mencionado em muitos lugares e tem o seu lugar ao sol em determinados usos (DataSet é um exemplo). Mas refere-se a record (registro) e em DDD uma entidade não é vista como um registro porque a persitência é abstraida e portanto existe uma incompatibilidade natural entre ActiveRecord e DDD.

Huh?!

Dá para explicar isso? Aliás, você realmente entendeu o que você acabou de escrever ou você acredita de fato nisso que você falou?

Explicar o quê ?

Agora acho que consegui entender tudo, muito obrigado, ficou bem claro, eu criei uma imagem mais nao consegui add aqui no post, peço que acesse o link para ver http://bp2.blogger.com/_i4__yipflbg/RnwLQi3uq1I/AAAAAAAAAAk/YD0lRgkGuHg/s1600-h/ddd.JPG

sergiotaborda wrote:
Pensemos agora que vc precisa organizar funcionalidades de dois domínios. Aqui vc usaria outro tipo de desenvolvimento. Eventos/notificações (EDD), SOA ou BPM. Isso é outro assunto.

Eu gostaria de saber como fazer isso, vc pode ser mais claro ?

***** EDITADO ********
Consegui anexar a imagem

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

ronildobraga wrote:Agora acho que consegui entender tudo, muito obrigado, ficou bem claro, eu criei uma imagem mais nao consegui add aqui no post, peço que acesse o link para ver http://bp2.blogger.com/_i4__yipflbg/RnwLQi3uq1I/AAAAAAAAAAk/YD0lRgkGuHg/s1600-h/ddd.JPG

É isso aí. Isso é a base da proposta de DDD.

ronildobraga wrote:

sergiotaborda wrote:
Pensemos agora que vc precisa organizar funcionalidades de dois domínios. Aqui vc usaria outro tipo de desenvolvimento. Eventos/notificações (EDD), SOA ou BPM. Isso é outro assunto.

Eu gostaria de saber como fazer isso, vc pode ser mais claro ?

Eu tb gostaria de saber fazer isso.

As tecnologias estão ai, o dificil nesta historia é encaixa-las...

J2Alex wrote:sergiotaborda,

O que você acha que há de errado na seguinte abordagem:

public class Conta { ... public void transferirPara(Conta conta, Double valor) { ... } .... }

Eu considero isso bem intuitivo e funcional...

Mas aí já estamos na área da arte, onde a arquitetura do software tem um que de cada um. Ou estão pensando mesmo em encarar engenharia de softwares como ciência exata e usar teoremas*.

Porque, se fosse assim, já teríamos IDE's com fómulas malucas, onde lançaríamos a entrada e sairia o software, exatamente de acordo com os livros do Fowler e do Evans.

Eu, por exemplo, prefiro utilizar Application Services (Core J2EE Patterns) para definir o workflow entre duas entidades diferentes, ou duas instâncias diferentes da mesma entidade.

Mas a abordagem do Alex também é interessante. Aliás, é bem freqüente ver discussão sobre isso em listas e blogs.

*Com teoremas, eu quis dizer algo como proposições que são observáveis e funcionam da mesma forma nas mais diversas cituações e, por causa disso, praticamente inquestionáveis, como a 1° lei de Newton.

sergiotaborda wrote:
Então, o seu servlet lê um request. Algum framework, ou vc na mão, lê os dados do request e decide o que fazer com ele. transforma os dados do objeto request num objecto comestivel ao serviço que executará a funcionalidade necessária. O serviço recebe esse objeto burro e entende o que vc pretende dele. Ele invoca os objetos de dominio necessários e executa o processo. Se ele tiver que retornar alguma coisa , essa coisa tb será um TO, que a camada que chamou o service converterá para um response, que o servlet enviará ao browser.

acho esta idéia bem interessante, mesmo para projetos que não usam uma arquitetura baseada em DDD.

sergiotaborda, parabéns pela explicação clara e objetiva.

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());
	}
}

//TO, VO, DTO novamente chamem como quiser
class LogonTO{
	private String name;
	private int key = 50;	
	... geters and seters
}

//Entidade do dominio
class PersonEntity{
	private int key = 50;
	... geters and seters
}

//Entidade do dominio
class LoginEntity{
	private String name;
	... geters and seters
}

//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() );
	}
}

Creio que seja isso, eu adicionei uma logica bem simples ao servico so para entender que la existe uma logica, seja ela qual for.
O repositorio segue as mesmas observação do primeiro exemplo

Alguns pontos que eu achei melhor nunca mais esquecer

Dominio = Entidades + Objetos de Valor + Serviços

O dominio é constituido de 3 "seres" : Entidades , Objetos de Valor (Value Objects , aka VO , mas não é a mesma coisa que DTO) e Serviços.

Entidades é tudo o que tem identidade (chave).

Objetos de Valor são classes auxiliares que agrupam muitos campos, como endereço, por exemplo

Serviços é aquilo que manipula as entidades para atingir um objectivo no dominio.

CRUD é um tipo de serviço com 2 operações que serve para alterar o universo de instancias de entidades e/ou objetos de valor

Repositório é uma forma padronizada dos objetos do dominio se encontrarem entre si. (Na prática é uma forma de encapsular a persistencia, mas em teoria não é esse o seu objetivo principal, já que eu posso persistir coisas que não são do dominio e/ou não persistir coisas que uso no dominio). O repositorio é por dominio.

logica de negocio é um conjunto de logicas de dominio.

Logica de dominio é interação entre entre os objetos de dominio

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.

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

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

uahuahuahuauha

PS: Tô por fora dessa thread, mas esse comentário foi hilário hahaha