Application Layer/ServiceLayer + Service(DDD) - Eric Evans e Martin Fowler

Olá

Nestes últimos dias estou relendo o livro Domain Driven Design do Eric Evans e poderia responder de forma simplificada a sua pergunta.

Mas isto não seria honesto comigo mesmo. Nada do que eu resumisse valeria um centésimo da leitura do livro.

Da primeira vez que entrei em contato com este livro fui só até o fim da parte II. Bem mais tarde li algumas coisas das partes III e IV. Agora decidi ler tudo de novo e até o fim. Trata-se de um livro fundamental.

O melhor conselho que posso lhe dar é: leia o livro.

Ah, só uma coisa. No livro do Evans, Service (DDD) tal como você escreveu não é uma camada e não se compara aos outros 2 conceitos. As divisões do que ele chama de arquitetura de camadas são: interface de usuário, aplicação, domínio e infra-estrutura. Serviços são apenas coisas que o software precisa fazer em algum momento sem precisar manter estado.

[]s
Luca

Você pode implementar em uma Service Layer do Fowler um Service do Evans. Se Evans diz que uma Service é um ponto de junção de várias classes de negócio para um determinado propósito e a Service layer de Fowler é a fronteira entre a aplicação e o negócio, ambos padrões podem ser co-relacionados.

O diagrama anexo de Fowler, mostra um Service de Lançamento de receitas (Revenue Recognition).

Tal Service (RecognitionService), que Fowler coloca na descrição como sendo um possível Stateless Session Bean, herda funcionalidades de um Application Service responsável por serviços de infraestrutura (por isso este outro é um Service de aplicação).

O RecognitionService não executa lógica de negócio, mas referencia objetos do domínio que as contém, possívelmente Entitys. Por isso também implementa o padrão Service do DDD, que agrupa um conjunto de funcionalidades (expostos por uma interface) em um determinado objeto (os Services) que delega as atividades para objetos de domínio.

O Service pode ser invocado pela Camada de Aplicação, por um ManagedBean do JSF, Action do Struts, etc, como sendo uma Façade. No Domain Driven Design Quicky, de Avram e Marinescu, eles mencionam que os próprios Frameworks implementam Services:

Domain Driven Design-Quicky:

Services act as interfaces which provide operations. Services are
common in technical frameworks, but they can be used in the
domain layer too.

[]s

2007/10/24/1ff3f3e796317280121098c5d3180bf2_2427.jpg754×295 28.2 KB

Cara, é que pelo que tenho lido (nas lidas saltadas do livro do Evans e dos artigos de Shoes) eu entendi que Service é conceito de domínio e portanto deve ser desacoplado de tecnologia.

O que raciocinei é que o ApplicationLayer seria o equivalente do ServiceLayer do Fowler, e que ele seria aquela parte que traz inerente a tecnologia específica. Por exemplo o sessionbean em java, ou o remoting do .net, ou o com+ do .net ou o webservice, etc.

Seria isso? Seria isso e mais alguma coisa? Isso que tow dizendo não tem nada a ver?

Ah, outra coisa. Luca, você que é o homem dos 1000 livros, estou quase comprando o DDD e o PoEAA. Vc recomenda que eu compre o PoEAA do Fowler em português mesmo, ou em inglês?

Lezinho,

Essas classes de nome Services do exemplo são services dentro do domínio né?

Olá

Compre o DDD e não se arrependerá. O PoEAA é ótimo mas segundo o próprio Fowler está um pouco ultrapassado. Acho melhor ler o site quando preciso de algum conceito dele. Gosto mais livro do Evans e coloco entre aqueles clássicos que todos devem ler.

Não aconselho ler o DDD Quickly antes de ler o livro todo porque pode atrapalhar o entendimento de alguns conceitos. É como escrevi no post anterior: nada como beber na fonte.

[]s
Luca

BiraBoy:

Cara, é que pelo que tenho lido (nas lidas saltadas do livro do Evans e dos artigos de Shoes) eu entendi que Service é conceito de domínio e portanto deve ser desacoplado de tecnologia.

O que raciocinei é que o ApplicationLayer seria o equivalente do ServiceLayer do Fowler(…)

Nos tempos de EJB 3.0, os objetos são POJOs. Portanto uma Session Façade pode ser um Service, exposto por sua interface, que mesmo assim não fere o conceito de Service de Evans, assim como tbm obedece os preceitos do Fowler.

Como citei no trecho do Quicky, Service é uma técnica que o DDD utiliza, mas que ja é antiga é usada pela maioria dos frameworks (não sou eu quem disse isso, é o texto).

BiraBoy:

Cara, é que pelo que tenho lido (nas lidas saltadas do livro do Evans e dos artigos de Shoes) eu entendi que Service é conceito de domínio e portanto deve ser desacoplado de tecnologia.

O que raciocinei é que o ApplicationLayer seria o equivalente do ServiceLayer do Fowler, e que ele seria aquela parte que traz inerente a tecnologia específica. Por exemplo o sessionbean em java, ou o remoting do .net, ou o com+ do .net ou o webservice, etc.

+1

A relação entre Service/Application Layer e Services DDD se dá como qualquer outra relação entre camadas, já que services DDD pertecem obrigatoriamente à camada de domínio.

Hmm… Em Java eu uso estrutura de pacotes.

Qualquer um, desde que seja útil pra você em determinada situação.

Pra mim isso é camada de apresentação, o que acha?

Independentemente de quem inventou os nomes e ou o que esses nomes significam é claro que existem classes que são apenas do dominio, classes que não são do dominio, e classes que fazem a ponte.

Os services do DDD são de dominio. Não são pontes. Eles são independentes da tecnologia da aplicação.
Se o Service DDD é invocado por um webservice, um stateless EJB um Action , um POJO ou directamente num scriptlet não faz a minima diferença.

A aplicação é o conjunto de classes que não são especificas do dominio mas que criam a interação dele com o usuário (usuário pode ser outra aplicação). Nessa estrutura existe um conjunto de conexões a serem feitas ( o chamado plumbing) e para as organizar normalmente se usam classes que desempenham serviços. Autenticação, autorização, controle de fluxo de UI , validação , até à propria UI em si. Essa é a camada de aplicação e nela ficam os serviços de aplicação. Que podem ou não invocar os serviços DDD. Podem por exemplo invocar métodos numa entidade diretamente. O serviços de dominio não são isoladores, são agregadores de lógicas que não cabem nas entidades. Os serviços de aplicação são isoladores. Normalmente baseado em algum padrão criacional e dependentes de uma tecnologia de arquitetura.

O termo Service Layer, sem um contexto não faz sentido , porque tudo o que isso significa é “conjunto de serviços”.

O que importa é saber o conceito e não o nome, nem quem deu o nome.

Application Layer e ServiceLayer é a mesma coisa…