Facade x Service Layer

Alguem poderia comentar a diferença entre Facade(GoF) x Service Layer(Fowler). É correto ter um Facade por caso de uso? É correto ter um Service Layer pode Entidade do Domínio?

Service Layer pode ser considerada uma Facade. O inverso já não é verdadeiro.

Por definição, Service Layer define as operações disponíveis. Se você implementar sua Service Layer com a abordagem domain facade, terá fachadas leves sobre o Domain Model. Você pode optar por uma implementação operation script, e assim terá objetos com regras da aplicação, mas a regra de negócios vai permanecer nos objetos do seu Domain Model. Neste último caso a Fachada tem mais responsabilidades.

[quote=joellobo]Alguem poderia comentar a diferença entre Facade(GoF) x Service Layer(Fowler). É correto ter um Facade por caso de uso? É correto ter um Service Layer pode Entidade do Domínio?
[/quote]

Façade é um padrão genérico de implementação. O seu obejtivo é orquestrar vários objetos para uma finalidade bem estabelecida.
O Façade não é necessáriamente um objeto. Pode ser um conjunto de métodos estáticos. ( Os managers do JasperReport são um bom exemplo). A ideia é condensar código, ou seja, em vez de 20 linhas chamando deus e o mundo no seu sistema toda a vez que quer invocar algum processo do sistema, vc usa só uma, passa os parametros e pronto. Internamente o objeto executará as 20 linhas fazendo chamadas a deus e o mundo, mas o utilizador do Façade não sabe disso. Com o tempo essas 20 linhas podem ser 2 chamando 2 ou tres outros objetos.

Façade não é um Adapter, nem um Proxy, nem um Wrapper. Sua função é minimizar esforço de invocação e esforço de conhecimento ( o programador facilmente sabe chamar um método, mas dificilmente sabe replicar 20 linhas de chamadas a 10 objetos… ). Objetos como java.util.Arrays e java.util.Collections são exemplos de Façades

Service Layer é um pouco diferente, mas não muito. A ideia é isolar o dominio através de serviços. Ou seja, não ha invocações previligiadas ao objetos de dominio, apenas os serviços fazem isso. E são vários serviços. Eles forma uma camada (conjunto de objetos) dai o nome Service Layer (Camada de Serviço). Façade pode ser usado se um serviço orquestar outros serviços mas não é vital. Em tese todos os serviços sao façades já que orquestram os vários objetos de dominio, mas os nomes são diferentes relativamene à sua função. Façades são genéricos, Serviços são objetos de Dominio. Serviços têm interfaces bem definidas, Façades não têm que ter isso ( como disse, podem ser apenas métodos estáticos).

Tenho uma duvida:

[color=darkblue]Service Layer define as operações disponíveis. [color=blue]Se você implementar sua Service Layer com a abordagem domain facade, terá fachadas leves sobre o Domain Model. Você pode optar por uma implementação operation script, e assim terá objetos com regras da aplicação[/color], mas a regra de negócios vai permanecer nos objetos do seu Domain Model. Neste último caso a Fachada tem mais responsabilidades.[/color]
Pelo que vc falou teremos uma Service Layer, com Facades ou operation script? Ou seja dentro da camada de serviços teremos as facades/operation script?

Pergunta:
Tenho o seguinte cenário (legado), Apresentação || Controle || Classes de negócio = Business || DAO || Entidades anêmicas. Não estamos utilizando DDD!

O que acontece: Notei que esta aplicação possuia métodos na camada de negócio com muitas responsabilidades, e sugeri a equipe que dividice estas responsabilidades em vários métodos no Business e que fosse criado uma camada de serviço (Martin Fowler:Service Layer) para de certa forma, orquestrar estas chamadas a vários métodos. O ideal é uma FACADE ou Service?

Já estudei e trabalhei com as duas abordagens, mas sinto uma lacuna entre essas duas abordagens.

Vlw

Eu não entendi muito mas me parece que sua dúvida é entre usar um Façade ou algo como Transaction Scripts na Service Layer. Dado que voc6e provavelmente tem estruturas de dados e funções BO e VO) já que o modeo é anêmico eu diria que provavelmente a Façade vai te dar mais benefício. Para utilizar Transaction Script você teria que mover a lógica de negócios para este, então acho que Não é exatamente o que procuras.

Aproveita o refactoring e acaba com esse modelo an6emico de uma vez. Só lembra que não é porque ocê não tem um modelo an6emico que você usa DDD.

[quote=joellobo]Alguem poderia comentar a diferença entre Facade(GoF) x Service Layer(Fowler). É correto ter um Facade por caso de uso? É correto ter um Service Layer pode Entidade do Domínio?
[/quote]

Joel, eu escreví sobre isso na MJ “Design Patterns para um Mundo Real - parte 3”. Apesar de não ser catalogado, vejo dois tipos de padrões que você pode ter com relação a granularidade das façades que você têm na sua service layer. Uma façade por caso de uso ou uma façade por entidade forte. Isso pode variar mesmo dentro do próprio sistema.

Espero ter ajudado… num framework web component-based como o Seam a façade terá o gerenciamento da Conversation, então, é comum usar uma façade por caso de uso. Isso pode variar em outros ambientes.

PEAA = “When you see a Service Layer (133), a key decision is how much behavior to put in it. The minimal case is to make the Service Layer (133) a facade so that all of the real behavior is in underlying objects and all the Service Layer (133) does is forward calls on the facade to lower-level objects. In that case the Service Layer (133) provides an API that’s easier to use because it’s typically oriented around use cases. It also makes a convenient point for adding transactional wrappers and security checks.”

GOF = “Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use”

joellobo,

respondendo ou tentando responder a sua pergunta original, eu quero dizer que a diferença entre esses dois patterns é que a Façade do GOF tem a intenção de prover um ponto único de entrada para um certa funcionalidade, como por exemplo o fluxo de um use-case onde agruparíamos várias funcionalidades em uma única porta de entrada, ou ainda uma interface para vários sub-sistemas.

No caso da Service Layer ela é somente uma camada “fina” onde existe um pedaço pequeno da lógica do seu domínio.

Um bom exemplo de utilização de uma arquitetura com os dois design patters, seria o uso de uma remote façade ( utilizando um Session Bean ), e uma Service Layer utilizando POJOs com Spring.