Alguém sabe me dizer se conceitualmente as classes que dizem respeito a autenticação e autorização de uma aplicação fazem parte ou não do domain model de um sistema ? Ex: Usuario, Perfil, Aplicacao, etc. Apesar de a autenticação/autorização poder ser independente da opção utilizada para a sua camada de apresentação (Swing, Web, Mobile, ou até memso todas elas) eu também não vejo essas classes como negócio da aplicação e sim como infraestrutura, segurança, sei lá o que … alguém poderia contribuir nesse assunto ?
OBS: Nada de questionamentos sobre não estar utilizando segurança declarativa pois não é o caso.
Eu acredito também que o modelo de domínio deva conter apenas negócio e os dados deveriam chegar corretos para ela, mas se voce tiver um sistema acessados por varios clientes, como voce citou (web, swing e etc) como voce garantiria a autorizacao e autenticacao desse usuario sem ter uma autenticacao numa camada servico ou fachada? Talvez usando AOP seria bem interessante…
Mas a dúvida não é essa. A dúvida é se essas classes são ou não classes de Domain Model do sistema. Colocar uma fachada ou não seria outra discussão (Acho que deve ter sim).
Estou estudando isso a um pouco tempo e fachada, e pelo que vi, fachada nao faz parte do modelo de dominio, entao pra sistemas com varios tipos de cliente usaria como fachada. Já pra sistema com apenas um cliente (web por exemplo) faria com validacao na camada de apresentacao. Mas resumindo sua pergunta, eu IMHO nao acho que é classe de modelo de dominio… mas…
Nada impede que uma Façade faça parte do Domain Model. Façade, Observer e estes padrões mais ‘core’ não dizem respeito á organizaçãod e código e simplesmente modelam interações e comportamentos entre componentes de software, sem relação com cotnexto onde está inserido.
Normalmente requisitos de autenticação/autorização são ortogonais ao sistema e atualmente o que utiliza apra este tipo de funcionalidade é AOP, seja manualmente ou atraveś de um framework.
Facade nao seria apenas uma camada de frente para gerenciar servicos e modelos de dominio e encapsular da camada de apresentacao o que é feito? Poderia explicar melhor essa colocacao?
No mundo ideal, Usuário/Perfil/Grupo/Aplicação seriam as classes do domínio de uma aplicação de gerenciamento de usuários, possivelmente que operasse como o back-end para prover serviços de SSO através das aplicações existentes.
Se vc. se vê com classes deste tipo no modelo de domínio de uma aplicação em particular, é um sinal de alerta: será que isto deveria estar aí ?
Por outro lado, é provavelmente correto ter uma entidade que possua informações e/ou métodos de um “participante” de um processo de negócio.
IMO, a chave aí é ter a provisão para determinar quem é o participante de um processo de negócio vinculado a um usuário do sistema. Este mapeamento é um bom candidato a ficar isolado em um serviço definido por uma interface. A interface deve permitir associar um usuário ao identificador de participante e ao sistema. Quando houver necessidade de se implementar uma função de negócio que dependa de quem está fazendo a solicitação, utiliza-se outro método que, dado o usuário e o sistema, retorne o identificador de participante - e aí pode ser utilizado para determinar se a operação será executada ou não.
Por exemplo: Imagine um sistema de aprovação de despesas, com um caso de uso “aprovar despesa” onde especifica-se que a despesa só pode ser aprovada por um supervisor se o valor for menor do que a alçada definida para o mesmo. Caso contrário deve ser aprovada por um gerente.
“supervisor” e “gerente” podem ser mapeados por roles e determinados em tempo de execução via segurança declarativa e, portanto, não são problema. A questão no caso é determinar a alçada do usuário corrente. Esta é uma informação de negócio que pertence à aplicação de reembolso e, portanto, deve estar lá em algum lugar. É aí que entra o conceito de “participante”. Se vc. for pensar, ele é uma espécie de “proxy” do usuário da plataforma de execução dentro do seu sistema.
Voltando ao exemplo, o pseudo-código para o caso de uso de aprovação seria algo assim:
Obtem o usuário de plataforma atual
chama o serviço de mapeamento e obtem o identificador de participante
obtem o participante utilizando o identificador
obtem o valor da alçada
se valor < alçada, prossegue. Caso contrário impede o acesso.
Me desculpe a ignorância mas não entendi quando você disse que são ortogonais ao sistema e sobre a solução de AOP para login de um sistema. Poderia explicar melhor ?
Ok. Porém não é o meu caso. Meu sistema não gerencia usuários. Apenas utiliza dos dados que já existem em outro sistema que faz essa gerência mas esse sistema não me provê esse serviço de autenticação/autorização.
Mesma resposta acima.
Esse sim é o meu caso. Ai eu entendo que seriam as classes Usuário, Perfil, Recurso por exemplo. Porém elas são classes do Domain Model do meu sistema ? Acho que não.
Ok. Essa interface que você esta falando seria uma fachada de serviço isso eu já sei (alias eu sei o princípio de fazer login em um sistema. Não estou sendo irônico )
Você acha que no meu sistema eu poderia considerar essas classes como proxies ? Desculpe não entendi muito bem. Você poderia explicar melhor ?
Não são mesmo. Elas fazem parte do domínio do outro sistema que vc. mencionou.
Acho que vc. pegou a idéia (tb. sem ironia !), mas não estou falando de login, certo ? O login em si está fora do escopo dos dois sistemas.
[quote]
Você acha que no meu sistema eu poderia considerar essas classes como proxies ? Desculpe não entendi muito bem. Você poderia explicar melhor ?[/quote]
Usei o termo “proxy” de forma um tanto liberal. A idéia é que no seu sistema vc. tenha uma classe que represente um participante de um processo de negócio. Esta classe deve possuir um identificador que possa ser recuperado a partir da informação de login que existe no contexto de execução de determinado caso de uso, usando para tanto o serviço de mapeamento ao qual me referi - e que, no seu caso iria consultar o sistema de segurança.
Outras informações relativas ao seu sistema vão parar nesta classe tb, tal como, no exemplo que dei, o valor de alçada para aprovação de uma despesa.
Por quê esta classe no seu sistema ? Veja, o sistema de segurança pode não ser baseado em um back-end relacional - pense em LDAP, p.ex. Embora até exista um driver jdbc para LDAP, vc não vai querer fazer joins entre o LDAP e o banco relacional onde os dados do seu sistema irão parar, certo ?
Se você usa Spring, dê uma olhada no Acegi Security. Ele faz segurança dos objetos de domain usando AOP e é relativamente simples de usar, principalmente se você usar annotations.
)