Exibição de dados não são regras de negócio, são de aplicação. Existe algum pattern na camada de negócio para abstração do front-end? Uma solicitação a um repositório(camada de negócio) como “obterContasAtivas” exige uma implementação que atisfaça esta regra do negócio.
Posts acima um foi comparado com outro para chegar a conclusão de quem ambos seriam “derivados” e não contentores.
Mas gostaria de saber Shoes, sobre a pergunta que fiz:
[quote=eu]
Uma vez que a regra é mapeada para a linguagem do banco de dados relacional, ele contem esta regra. Isso é, se vocês considerarem que as assinaturas de um repositório são regras…[/quote]
Você considera as assinaturas do repositorio como regras pertinentes ao dominio?
Voce esta confundindo dominio com regras de negocio. A Camada de Aplciacao, assim como a Camada de Dominio, possui suas regras de negocio aplicadas de alguma forma. Uma interface com o usuario tem que obedecer regras de negocio da mesma maneira, o fato de nao existir uma abstracao de negocios para interface eh mera consequencia de uma arqutietura de camadas.
Na verdade, no idioma do usuario -o que vem escrito nas user stories- nao existe “obter contas ativas”, existe eh " exibir contas ativas".
Quanto a sua pergunta, pense dessa forma: java.util.List nao eh parte do meu dominio e ainda assim eu o uso para implementar minhas regras de negocio. Da mesma forma SQL nao faz aprte do meu dominio mas eu o uso para implementar minhas regras de negocio.
Tentando resumir: um DAO nao implementa regras de negocio, ele implementa mecanismos que as classes que implementam regras de negocio usam. 'E parte da infra-estrutura da aplicacao. Obviamente que o codigo que gera um WHERE vai estar vinculado a uma regra de engocio mas TUDO num sistema esta vinculado a regras de negocio. A criacao de uma clausula WHERE nao eh implementacao de regra de negocio, eh consequencia desta.
No exemplo que citei a user case pode implicar em “obterContasAtivas()” para efetuar lançamento de malas diretas sobre estas. A primeira tarefa é requisito do domínio. A interface List não possui métodos para lhe retornar este requisito do domínio, mas um repositório pode ter.
Logo, se na implementação de um repository, você utiliza SQLs, EJBQLs, QueryObjects para implementar esta regra de negócio, seu repositório possui regras, conforme seu quote.
PS: [preferenciaPessoal] DAOs não implementam regras de negócio mesmo, eles apenas se comunicam com o banco. Por isso que prefiro uma implementação de Repository onde as montagem de QueryObjects(implementação da regra para consulta) estão nelas e então este o repassa para um DAO executor em outra camada se comunicar com a infra.[/preferenciaPessoal]
Relendo seu post Shoes, acho que entendi seu ponto de vista e talvez todos aqui estão dizendo a mesma coisa. O fato é que a afirmação de repositório não conter regras de negócio é muito relativa, pois depende do que o analista observa como “regra de negócio”. Todo o sistema tende a colaborar com o dominio, dado a isso a consequencia do comportamento é refletida em todo o sistema, juntamente com o domínio.
Sim, eu n~ao falie que repositorio nao temr egras, falei que eu nunca vi um caso.
Uma dúvida:
Quando algumas regras de negócio se encontram em procedures/functions no banco de dados, pode-se dizer que as regras estão contidas no repositório?
[quote=rponte]Uma dúvida:
Quando algumas regras de negócio se encontram em procedures/functions no banco de dados, pode-se dizer que as regras estão contidas no repositório?
[/quote]
Não. Nesse caso as regras estão em um sistema externo e a melhor maneira é abstrair através de um Service de fachada, creio.
Botões, textfields e companhia não são regras de negocio, mas o seu comportamento e disposição são.
A expressão “regras de negocio” é tlv demasiado limitativa. Eu me referia a requesitos.
Os controles não são requisitos em si, mas eles cooperam para atender aos requisitos.
Os requisitos dividem-se em dois grupso: funcionais (RF) e não-funcionais (RNF). Os RNF são de segunrança, arquitetura, ergomia, etc… os controles em si caem nesta area. Os RF são normalmente o que se designa por dominio em DDD mas não é uma relação 1:1.
A ideia que os repositorios contêm logica de negocio porque são responsáveis por escrever pesquisas é simples de entender. As pesquias dependem do modelo: dependem da estrutura fisica do modelo e das estrutura abstracta do modelo ( as regras ). Se existem uma tabela pessoa com uma tabela endereço associada a pesquisa é feita de uma forma, se existe apenas uma tabela, a pesquisas é feita de forma diferente. A mudança de regras de negocio , aka RF , implica na alteração das regras de pesquisas e portanto na alteração do repositorio onde essas pesquisas são criadas. É por isso que o repositorio é um elemento do dominio e não de infra. Elementos de infra não se alteram conforme os RF, apenas com os RNF. Esta diferenciação é importante porque os RNF são o que os frameworks da praça resolvem. Nenhum framework pode resolver RF (embora existam padrões especiais para alguns RF chamados padrões de aplicação). clientes pagam para que RF sejam implementadas. Normalmente eles não enxergam RNF ou os veêm juntos com RF.
O modelo por detrás dos controles depende dos RF. A famosa “o combo X muda comforme o combo Y” é um RF.
“Regra de Negocio” é um termo especial que define RF especiais. São aquelas regras que mudam conforme se muda de cliente. Clientes diferentes têm um nucleo de regras diferentes e um nucleo de regras iguais. Todas são RF, mas a evolução delas é diferente. Regras que mudam conforme a area de atuação do cliente/sistema são Regras de Dominio e aquelas que mudam de cliente para cliente na mesma area são regras de negocio.
Por exemplo , todas os comercios emitem nota fiscal e quase todos trabalham com o conceito de pedido. Isso é uma regra de dominio. No dominio das empresas de serviços à uma ordem de serviço e não um pedido. No dominio de medicina não existe pedidos, nem no de bancos.
Médicos têm historicos dos pacientes. Isso é uma regra de dominio. Como eles têm acesso a esse historico e o que o historico contém é uma regra espcifica do cliente: Regra de Negocio.
Bancos têm clientes e estes têm contas. Isso é uma regra de dominio, mas as informações que eles contêm são regras de negocio.
Regras de Negocio evoluem muito mais depressa que as de dominio (bancos não deixarão de ter contas para clientes tão cedo).
Em DDD não ha uma distinção entre este dois tipos de regras. Existe o Dominio e ponto final. Todos os RF estão no dominio ou são abordados por ele em alguma medida. Tudo o resto é RNF e é resolvido com frameworks e/ou codigo de estrtutura.
A confusão que se sente é que as pessoas confudem “CRUD” com regra de negocio , como se o ato de gravar/alterar depende-se do negocio. Isso é falso. Ele depende na realidade do processo do dominio que necessita de entidades. CRUD é uma forma de alimentar as entidades para o dominio. (Outra seria importação de dados, por exemplo). Fazer um insert não é uma regra de negocio, mas o como se faz o insert para aquele sistema em particular é. Por isso que cada sistema tem os seus inserts e dificilmente (impossivelmente) uma frase SQL usada por um sistema pode ser utilizada por outro. Acho que isso mostra obviamente que o SQL depende e expressa regras de negocio: RF que mudam de cliente para cliente.
CRUD não é uma regra de negocio, mas a implementação dele depende das regras.
Se pensarmos bem, um sistema sempre é algo que se limita a alterar um estado através de um processo. ele pode ter vários processos alterando o estado, mas tem apenas um estado. Para que o altere ele precisa consultar esse estado antes. Isto é o arroz-com-feijão de qualquer software. O estado depende das regras dos processos que são RF. O estado tem que ser preservado porque ele detêm a identidade do sistema. A preservação do estado é decorrente da existencia do proprio estado tal como a preservação da vida é decorrente da própria vida. Preservar o estado, contudo, ainda é uma tarefa em que existem RNF e RF operando simultaneamente. Comunicar com o banco via JDBC é RNF , mas o quê comunicar é RF.
DAO é o cara que se comunica, ele é um RNF e por isso ele pode ser reaproveitado. Ele transfere SQL , mas ele não cria SQL.
Repositorio contém vários RF e por isso ele não pode ser aproveitado e depende de alterações nos RF.
Exactamente por isto que existem 2 padrões e não apenas um. Exactamente por isto um pode ser definido como interface e outro não.
Tudo num sistema está vinculado a requisitos, mas nem tudo está vinculado a regras de negocio ( requisitos funcionais). É isso que diferencia arquitetura e design. Arquitetura preocupa-se apenas com requisitos não-funcionais e design preocupa-se em embutir requisitos funcionais em cima da arquitetura. Todos os frameworks que existem fazem muito, mas fazem apenas RNF. Sempre, em todos eles, existe uma ponta que o utilizador tem que extender para poder incluir RF. O DDD tem apenas a ideia de que os RF devem ser isolados completamente dos RNF de forma que possam ser reaproveitados entre várias arquiteturas. Se isso não pode acontecer, o modelo de dominio ficou “sujo” com regras de infra. Isso é errado em DDD. Aliás é errado em OO e em programação de uma forma geral. Contudo em casos reais nem sempre é possivel fazer isso. Na maiorias das vezes porque o dono do negocio não entende que ter um nucleo de dominio indepenente diminui custos em longo prazo. Ele só vê o aumento a curto prazo já que um modelo de dominio independente é muito ccomplexo de construir e essa complexidade aumenta proporcionalmente à distribuição do sistema. Pior, os desenvolvedores também ainda não entenderam este conceito.
Como saber se um objeto depende de regras de negocio ( requisitos funcionais) ?
Simples, sua implementação mudaria se as regras mudassem ?
Algums exemplos:
String : não depende
List : não depende
Comparator : depende
Entity : depende
Service : depende
RMI : não depende
Serialização : não depende, mas pode depende se necessário.
DAO: não depende. Ele apenas muda se a tecnologia de persistencia mudar.
Repositorio : depende.
Action do Struts : depende.
Servlet de Controle do Struts : não depende.
JTable : não depende
TableModel : depende.
QueryObject : não depende ( embora possa ser implementado para depender)
Specification : depende
Acho que é simples de aceitar que Repositorio contêm regras de negocio. E não depende de como se define regra de negocio já que o estado do sistema que o repositorio pesquisa é o reflexo dessas próprias regras; quaisquer que elas sejam.
Tsc, tsc tsc… Resta saber se o Owner do tópico já entendeu a duvida ou se ele desistiu do ‘Chat’…
Excelente perguntinha!! Talvez eu nao concorde com alguns depende/nao-depende, mas o importante é a pergunta e o caso de cada um!!
Opa, não desisti do post não! Estou acompanhando tudo! As discussões estão me ajudando muito!
Estou terminando de ler o Nilsson, e já volto com mais dúvidas! 
[]'s