emerleite wrote:Já discuti isso (e muito) com o Gustavo pessoalmente nesta semana, então não vou me repetir textualmente.
O ponto que eu acho que a maioria defende é o fato de não fazer BDUF e a filosofia de YAGNI. Não faz muito sentido fazer implementações na base da suposição, como por exemplo: Vou interfaciar usando DTOs, pois estou prevendo acesso remoto.

Gustavo Serafim wrote:

sergiotaborda wrote:
Por outro lado, o desenho do exemplo de funcionário não contém métodos que alteram o estado do sistema, logo, não ha nenhum perigo em invocar esses métodos de qualquer outra camada.

Alterar um atributo de instância de um objeto de negócio não é alterar o estado do sistema? Se você esta falando de base, esses objetos podem ser gerenciados por um mapeamento objeto relacional como, por exemplo, o Hibernate.

Gustavo Serafim wrote:

sergiotaborda wrote:
Por outro lado, o desenho do exemplo de funcionário não contém métodos que alteram o estado do sistema, logo, não ha nenhum perigo em invocar esses métodos de qualquer outra camada.

Alterar um atributo de instância de um objeto de negócio não é alterar o estado do sistema?

Lezinho wrote:

Gustavo Serafim wrote:

sergiotaborda wrote:
Por outro lado, o desenho do exemplo de funcionário não contém métodos que alteram o estado do sistema, logo, não ha nenhum perigo em invocar esses métodos de qualquer outra camada.

Alterar um atributo de instância de um objeto de negócio não é alterar o estado do sistema? Se você esta falando de base, esses objetos podem ser gerenciados por um mapeamento objeto relacional como, por exemplo, o Hibernate.

É discutível.
1)Gostando ou não de getters and setters, eles mantém o encapsulamento na camada de domínio. Você não mudou o estado em outra camada, você sugeriu para o setter(que esta no domínio) assim o fazer ... Dependendo da implementação deste útlimo, ele altera o estado do objeto (de forma persistível ou não).

2)Mesmo se assim não fosse (suponhamos que o atributo fosse público), o objeto de negócio poderia ter seu estado de forma transitória, já que a classificação de alterado poderia ser somente quando este atinge o status de 'pronto', através de alguma implementação de sustentação deste estado (persistindo ou serializando por exemplo). Nestes casos, alterar um atributo pode não significar mudar seu estado, já q ele não esta 'pronto' (se alguém solicitar pelo seu identificador, atraves de um repositório este mesmo objeto, ele estaria com outro estado, diferente que o seu).

O ponto 2 que coloquei é verdade dependendo de implementacoes de cache e proxies utilizadas no sistema.

Gustavo wrote: No caso usei um prefixo set.., mas estou representando um método de negócio.

Lezinho wrote:

Gustavo wrote: No caso usei um prefixo set.., mas estou representando um método de negócio.

Então melhor ainda. Quem tem o método de negócio, como você mesmo descreveu, é o método "set" é ele que pode (mas não necessariamente faz) a alteração de estado. O execute do Command é um delegador para o domínio (entre outras atividades), mas não tem regra quanto a ele.

Fowler wrote:
A camada de serviço encapsula a lógica de negócio da aplicação, controlando as transações e coordenando as respostas na implementação das suas operações.

Gustavo Serafim wrote:
Na verdade, esse exemplo é muito simples e não vai justificar uma abordagem mais complexa como decomposição em camadas. (LayeringPrinciples) Abordagens como Business layer, CBD e Manter o estado dos objetos consistentes se destinam, na maioria das vezes, a supera limitações humanas, como lidar com grande quantidade de informações ou complexas (regras de negócio complexas ).

Gustavo Serafim wrote:

pcalcado wrote: O que se ganha nisso?

Phillip, qual parte? "Proteger a implementação" ajuda diminuir o acoplamento. "Manter objetos sempre em estado consistente" ajuda muito quando temos muitas regras complexas. Quando temos muitas trocas de mensagens para cumprir uma regra complexa, podemos inserir erros de lógica de negocio mais facilmente quando os objetos ficam inconsistentes em algum momento.

Gustavo Serafim wrote:
Se você diz que manter uma hierarquia de interfaces e fabricas não é mais trabalhoso, então eu acredito.

Tanto interfaces quanto objetos "burros" protegem a implementação de um componente de negócio, então acredito que as duas abordagem são úteis para componentes de negócio.

Lezinho wrote:Invocação não significa implementação do domínio... o código continuara na camada adjacente. O que obviamente não seria interessante é o domínio conhecer algo da application, o que não é o caso.

PS: Não estou entrando no mérito de façades pq acho que não é o ponto.

Lezinho wrote:
O ponto onde você atacou era duplicar os objetos Gustavo, e não criar uma façade de serviço, por isso minha observação acima.

Lezinho wrote:Desculpe, mas o que tenho postado até aqui não tem nada haver com ServiceLayer, tem haver com sua solução na duplicação de objetos como solução para não vazer "regras". Se vc discutia outra coisa, que só ficou clara no ultimo post, não era comigo.

rob1980a wrote:alguma solucao pratica para o problema? Mapear com interfaces quando necessario? Como mapearia o meu MB?