A primeira rede social sobre arquitetura de software do Brasil

DDD + SOA ou DDD + BPM?

Vejo, com frequência, várias pessoas falando sobre SOA e DDD como algo adjunto ou complementar. Acredito que isso é errado. Se formos pensar no estilo arquitetural baseado em serviços (SOA) não podemos dizer que DDD é uma forma de modela-lo. SOA é composto de blocos de construção diferentes do DDD, bem como a granularidade em que estes blocos são criados são diferentes.

Um dominio ou área de aplicação como gostar de chamar, é um problema a ser vislumbrado, entendido e resolvido. Um serviço é um componente com um conjunto de operações (tarefas) correlatas que foi concebido a partir de um processo de negócio ou elemento do legado de TI de uma corporação com base em seu foco no negócio.

Neste caso, podemos ver claramente que um dominio pode sofrer técnicas de decomposição do problema, mas um serviço, já é uma unidade atômica resultado de práticas de decomposição de processos. É mais coerente então criar um mix entre DDD com BPM (Business Process Management) do que DDD e SOA.

Entendido a diferença, recomendo fortemente o cuidado com os empregos de conceitos. Muitas das vezes, somos vitimas de modismos e hypes instituidos por pessoas que normalmente não entendem completamente alguns conceitos. No que tange a SOA, a probabilidade de alguem estar falando besteira sobre o assunto é muito grande, pois SOA é muito amplo para ser definido em pequenos conceitos.

Fica ai a dica ;)

▶ Responder esta

Respostas a este tópico

Permalink Responder até Marco Mendes em 18 outubro 2008 at 16:35: Boa tarde, Ricardo. Enquanto o churrasco nao chega, vamos ficar aqui discutindo arquitetura :p.
Concordo parcialmente com a questão do DDD e SOA. Se olharmos dois padrões arquiteturais que embasaram DDD e SOA, iremos ver respectivamente o padrão Domain Model (para DDD) e os padrões Transaction Script.e Service Layer para SOA.
http://martinfowler.com/eaaCatalog/transactionScript.html
http://martinfowler.com/eaaCatalog/serviceLayer.html
http://martinfowler.com/eaaCatalog/domainModel.html

O padrão Domain Model realmente é antagônico ao padrão TransactionScript, o que implicaria que DDD e SOA seriam incompatíveis. Entretanto, vejo uma alternativa, que é o uso do DDD em "domínios locais" de aplicação onde poderíamos usar o DDD em toda a sua força, mas com a adição de uma camada "procedural" de servços. Em verdade, o proprio padrão Service Layer permite, na sua estrutura, que ele enlace um modelo de domínio. Desta forma poderíamos compatilizar estas visões de mundo. )
O que vc acha?; ▶ Responder esta

Permalink Responder até Ricardo Ferreira em 18 outubro 2008 at 17:40: Grande Corélio,

Acho pertinente sua idéia, realmente dominios locais podem ser mapeados para um conjunto discreto de serviços que representam uma área do problema particular. Eu gosto de pensar em serviços como peças independentes de um problema particular, gosto de olha-los sob a ótica de: funcionalidade x coesão x reuso. Sendo assim, acho um pouco dificil (mas acredito não ser impossível) obter bons serviços reutilizáveis em nível corporativo, se estes estiverem focados em um problema particular.

Neste caso, acho que é valido sim pensar em modelo de dominio sob o encapsulamento de serviços, mas tendo a desconfiar se tais grupos de serviços não terão realmente sua reusabilidade afetada por estarem ligados a um dominio. Claro que, reusabilidade é uma palavra pomposa. Dizer que tal serviço é reutilizável, deve vir acompanhado da sentença: Sob a ótica de quem? O reuso em SOA está quase que sempre ligado a cross-departments, silos, cross-companies. Mas também podemos ve-lo como um dominio particular, por exemplo, um conjunto de serviços voltados a segurança da informação. Nestes casos, estamos falando de dominios locais, e o serviceLayer aplica-se coerentemente.

Concluo então que, se delimitarmos as fronteiras de reuso, podemos sim chegar em níveis de dominios que facilmente podem ser mapeados para um conjunto discreto de serviços, estando portanto, de acordo com você, Corélio!

Aproveitando o post: O Martin Fowler é um Nerd Java de carteirinha ... repare como nas URL's do seu site ele usa o padrão de nomenclatura da Sun :P; ▶ Responder esta

Permalink Responder até Denis Oliveira em 19 outubro 2008 at 0:15: Bom.. minha humilde opinião:

Business Services são geralmente agrupados e distribuídos em aplicações dentro de um mesmo contexto de negócio.

Por exemplo, um processo de negócio de E-Business envolvem serviços expostos por aplicações CRM, ERP, SCM, ...
Em uma aplicação CRM, você terá um domínio específico. Conceitos como "Cliente", "Prospect", "Campanhas" são geralmente classes do domínio de aplicações CRM. Poderia então, existir um processo para transformar um "Prospect" em um cliente através de uma campanha. Note que essa linguagem é a linguagem usada por usuários das áreas de marketing e vendas. Só que esse processo é algo que atravessa a fronteira do sistema CRM, pois um CRM por si só, não tem ou deveria ter "poderes" para isso. Ou seja, um sistema CRM não tem poderes para vender um produto para um cliente no seu contexto isolado. No contexto do sistema CRM, você poderia usar DDD (como diz o Marco Mendes) "em toda a sua força". E então, expor operações de negócio como serviços.

Uma coisa em comum entre DDD e SOA: Ambos procuram falar a linguagem do usuário.; ▶ Responder esta

Permalink Responder até Ricardo Ferreira em 19 outubro 2008 at 9:23: Denis,

Eu concordo com voce em genero, número e grau. Voce está certissimo. Assim como concordo com o Corélio sobre o uso do serviceLayer num dominio local. Mas na sua frase: "E então, expor operações de negócio como serviços", é ai que eu vejo um "Separation of Concerns" dos mundos DDD e SOA, e mais ainda, é neste caso onde eu vejo que DDD é inadequado para a construção de serviços SOA, e portanto, o paradoxo "DDD is a good approach for SOA modeling" se torna meu algo de crítica. Deixe-me explicar porque ...

- Um serviço SOA requer que vários aspectos voltados a orquestração de serviços e integração de dados sejam levados em consideração. Por exemplo, serviços devem ser Stateless. Isso significa que toda a conversa entre dois serviços deve ser modelada em cima de verbos e operações que retornem o estado e contexto de uma forma anterior. Isso prejudica demais a elaboração de services do DDD (mais ainda sendo possível) e de cara já elimina entidades e valueObjects da jogada.

- Pensando que um service do DDD ainda pode ser usado para uso numa infra-estrutura SOA, ele se tornará antiquado devido as suas dependencias. Um service faz na verdade acesso a uma ou mais entidades e/ou valueObjects para executar suas operações e normalmente estes elementos são usados como valores de retorno e argumentos das operações (seus verbos). Candidatar um serviço para ser usado num contexto SOA é matar algumas premissas básicas de fraco acoplamento e reuso do SOA. Os tipos de dados que devem ser usados em serviços SOA devem ter algumas preocupações intensas sobre interoperabilidade. Sendo assim, o caso mais clássico que vejo nestes casos, é a criação de uma fachada para encapsular o acesso a estes elementos de um dominio local, bem como a criação de complex types para auxiliar o mapeamento dos verbos (operações) dos serviços. Lá vai outro elemento do DDD por água abaixo novamente ...

- Um serviço SOA deve ter boas doses de granularidade. Isso se faz necessário porque se o serviço for gordo demais, ele poderá comprometer a reusabilidade. Se ele for magro demais, durante composição de processos e coreografia, o custo com serialização e chamadas remotas também pode ser alto, e comprometer SLAs de desempenho do serviço. Neste caso, as técnicas que governam a criação de um serviceLayer para um dominio local podem afetar estes requisitos. Por exemplo, um service do DDD IMHO é uma abordagem sobre coesão de operações. Se numa bateria de modelagem eu acho operações de um dominio (Responsabilidades de um cartão CRC, por exemplo) e este não se aplica devido a coesão a nenhuma das minhas entidades ou valueObjects, e iria criar um susbstantivo que mapeasse todos estes verbos que estariam órfãos no domainModel, criando portanto um service. Isso poderia conceber um serviço ou muito pequeno ou muito grande.

- Outro ponto importante, é que em projetos SOA, normalmente antes do momento da criação de um serviço, ou se o contexto é iterativo-incremental, a disciplina de desenho de serviços tem como pré-condição a disciplina de desenho de dados. Isso se faz necessário porque grande parte dos problemas de integração de aplicações se dá devido a incompatbilidade dos tipos e formatos de dados existentes nas aplicações. Sendo assim, um trabalho de federação de dados pode estimular fortemente o desenho de serviços, de certa forma, coagindo-o diretamente. Isso tentencia o desenho dos serviços, virando um problema sério na hora de buscar potenciais serviços em dominios locais, esbarrando no ponto das dependencias e tipos de dados.

- Finalmente, SOA é uma abordagem que tem foco no negócio, mas sua realização é 100% técnica. Isso significa que até o momento onde estamos discutindo o negócio de uma empresa ou mesmo uma solução de processo para integração de departamentos ou empresas, não teremos que nos preocupar (ainda) com metade das preocupações que expus aqui e que inviabilizariam o domainModel. Neste caso, ainda defendo a idéia de que DDD está bem mais atrelado a modelagem do negócio do que a modelagem de serviços. DDD conforme já discutido antes aqui, é uma abordagem muito mais alto-nivel do que detalhes de implementação.

Sendo assim, o problema SOA + DDD se torna evidente quando descemos para o nível de implementação. Eu acredito que por sermos desenvolvedores no final das contas, nos sentimos tentados a sempre tentar pensar num conceito no ambito de implementação, e acabamos, no contexto de implementação, achando similaridades nos principios. Mas acredito que DDD é muito mais rico e bonito que implementação de sistemas, ele torna a concepção e realização de um dominio qualquer algo pragmático, algo que nós como criadores de soluções de TI devemos nos beneficiar.

Valeu Denis!; ▶ Responder esta

Permalink Responder até João Henrique em 20 outubro 2008 at 11:56: Olá,

A discussão chegou num nível de complexidade técnica que ta bem acima da minha experiência.
Nunca participei de um projeto SOA, então não posso opinar sobre questões da fachada de serviços pra cima.

Mas, se não forem utilizar um modelo de domínio para a implementação de um conjunto de serviços, utilizariam transaction Script?

Qual a diferença então, já que as duas soluções podem ser encapsuladas por quaisquer fachadas e adaptadas a quaisquer tipos de clientes?

Se acima disso é utilizado SOA, ou um simples cliente swing, depende somente da adaptação dos seus serviços.

Complementando, a implementação via domain model é UMA das premissas do DDD.
Existem outros conceitos importantes, como a ubiquitous language, a participação ativa do cliente na modelagem, evolução constante do modelo e envolvimento de toda a equipe com o domínio.; ▶ Responder esta

Permalink Responder até Júlio César e Melo em 23 outubro 2008 at 20:27: "Fowler describes the transaction script, which separates UI from application but does not provide for an object model. The bottom line is this: If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven design."

Eric Evans. Domain-Driven Design -- Tackling Complexity in the Hear...; ▶ Responder esta

Permalink Responder até Marco Mendes em 23 outubro 2008 at 23:03: Ditto! ;); ▶ Responder esta

Permalink Responder até Ricardo Ferreira em 24 outubro 2008 at 19:51: "The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about."

Para consulta: http://www.martinfowler.com/bliki/AnemicDomainModel.html

:-); ▶ Responder esta

Permalink Responder até Breno Barros em 29 outubro 2008 at 15:27: Olá a todos. Boa tarde.

Antes de tudo, eu gostaria de frisar que este é um assunto polêmico e que, a visão de vocês retrata exatamente o que eu penso. ;)

Enfim, eu li os comentários de todos e mesmo concordando com o ponto de vista de cada um, eu defendo um pouco mais a visão do Ricardo Ferreira, com a idéia que o DDD está mais para técnicas de negócios do que para implementação SOA. Onde irei procurar ser breve, até porque vários pontos técnico já foram levados a tona.

Nesta linha, o que me faz defender esta idéia é a seguinte:

Na minha visão, SOA é uma abordagem que tem como foco prover interoperabilidade e flexibilidade, para em suma, melhorar o time-to-market, ROI e payback dos negócios corporativos de uma organização alvo. E caso essa visão não seja levado em consideração, podemos voltar aos velhos problemas de criação de novos silos de informações.

Desta forma, quando falamos de "serviços SOA" ou "business services", normalmente estamos referenciando aspectos de reutilização a níveis corporativos (cross-departaments e cross-companies) e não a um domínio particular. As granularidades e atomicidades neste nível corporativo são normalmente altas e compostas, respectivamente. Com isso, vejo que para a disciplina de implementação o DDD não é recomendado. Já para a disciplina de modelagens de negócios o DDD pode ajudar durante os ciclos de decomposição dos processos de negócios.

Porém, para "infrastructure services" e até mesmo para "information ou data services", podemos sim aplicar na disciplina de implementação, o DDD. Entretanto, o problema exposto pelo Ricardo Ferreira: "...problemas de integração de aplicações se dá devido a incompatbilidade dos tipos e formatos de dados existentes nas aplicações..." É um fato e aqui está um ponto fraco do DDD, na minha visão. Onde para evitar isso, eu prefiro abordagens como Master Data Management (MDM) com federação de dados e/ou a criação de um Modelo Canônico com Enterprise Business Objects (EBOs), para evitar esse tipo de problema.

Espero ter contribuido com algo.

Um abraço a todos.; ▶ Responder esta

Permalink Responder até Júlio César e Melo em 6 novembro 2008 at 17:03

Achei um pequeno artigo (duas páginas) pertinente a essa discussão escrito por um pessoal daqui do Brasil.

MARZULLO, Fabio; SOUZA, Jano de; BLASCHEK, José. A Study Case on Domain-Driven Development, using MDA, SOA and Web Services. IEEE Congress on Services 2008.

Segue aí o resumo e o artigo anexado:

This paper presents preliminary study results of a prototype architecture created with the purpose of using a domain-driven approach to shorten the development of software projects. Using a set of standards and theories such as MDA, SOA and Web Services, the proposed architecture indicates that, with the aid of standard and controlled techniques, it is possible to obtain significant gains on software scheduling and cost.

Anexos