Dados vs Domínio

Parece que a diferença entre um sistema orientado ao domínio e um sistema orientado a dados ainda não está bem clara. Isto é um problema importante porque sem a clara diferenciação entre os dois paradigmas não é possível entender e comparar as vantagens e desvantagens de cada um.

Em um sistema orientado a dados o mais importante é o ciclo de vida dos dados. Criação – Preservação – Procura – Edição/Remoção – Atualização. Normalmente o foco é a Preservação. Historicamente estes são os sistemas que deixaram marca na TI até ao início do século XXI. Todas as linguagens e produtos comerciais tentavam facilitar este ciclo ao máximo deixando os programadores se focarem nas “regras de negócio” – que basciamente significa deixar-los se preocuparem com as amarrações entre os dados. A invenção e introdução dos bancos de dados relacionais com poderosas capacidades como stored procedures (rotinas preservadas junto aos dados), triggers (tratadores de eventos) e, claro, constrangimento relacional (mecanismo que força as regras de “amarração”) foram o expoente máximo dos sistemas orientados a dados. Assim era possível incluir todo o ciclo dentro de um SGDB com suporte transacional e concorrente.

Mas eis que chegou a Internet. Este singelo pedaço de tecnologia alterou a forma como as empresas precisavam se relacionar com seus parceiros e clientes: nasceu o comércio eletrônico. Agora, mais do que nunca, os sistemas de TI eram o cérebro e os braços por detrás do negocio. WebServers e CGI passaram a fazer parte da vida dos programadores. Mas os sistemas ainda eram orientados a dados. A diferença é que os dados eram recolhidos remotamente de um navegador ao invés de um sistema escrito com a linguagem de eleição.

O Java nasceu focado em um único propósito: independência. Uma paltaforma pronta a rodar em qualquer lugar em qualquer SO se tornou apta a rodar em qualquer navegador. O Applet marcou história e levou a internet a um nivel mais utilizável. A facilidade de programar para a web aumentou depois com a Servlet API, a JSP API, e hoje dezenas de frameworks tentam elevar a produtividade da API de Servlets e JSP. Mas os sistemas continuaram orientados a dados. O Banco de Dados reinava soberano, mesmo em sistemas criados com linguagens orientadas a objetos e especialmente em Java.

O primeiro passo para uma quebra de paradigma foi a especificação Enterprise Java Beans (EJB) que em nada se relaciona com a especificação JavaBeans. A EJB trouxe várias vantagens aos programadores Java. Além de aplicações remotas trouxe o primeiro modelo de aplicação que não era orientado a dados. Demorou algum tempo até que alguém avançasse com um nome para esta nova forma de fazer as coisas: modelo orientado ao domínio. Os dados eram agora apenas um terço (no início mais que um terço, já que não existiam Message Beans) de um sistema. Tinham agora que partilhar seu espaço e relevância com a “Sessão”. A sessão foi um conceito forjado em cima das aplicações web quando a importância desdes sistema ficou óbvia. Eles só eram úteis se fosse possível que o navegador submetesse comandos ao servidor e o servidor os identificasse como pertencentes aos mesmo “contexto de trabalho”: a sessão. O conceito foi levado para a EJB com os Session Beans (com estado e sem). Os Session Beans bem se poderia chamar de Service Beans, mas historicamente o termo “serviço” ainda não era usado ou popular (tornou-se popular como a SOA e os WebServices bem mais tarde – onde, claro, os Stateless Session Beans eram os seus pares exatos).

Mas o modelo EJB estava muito à frente do seu tempo (como aliás a maioria dos paradigmas que aparecem pela primeira vez com o Java). Os programadores continuavam pensando e escrevendo programas orientados a dados. Session Beans eram apenas portas remotas por onde enviar os dados ao servidor, e os Entity Beans apenas objetos de dados ultra-complexos. Ninguém percebeu, realmente, que os Entity Beans eram controladores de dados que deveriam cuidar do ciclo de vida do dado (coisa que antes era feita pelos bancos de dados e até por sistemas inteiros) e não representar os dados em si. A Sun, por meio dos seus J2EE Design Patterns tentou explicar como usar a EJB. Vários formatos, padrões e mecanismos de ajuda foram apresentados, mas o sucesso foi aquém do que poderia ter sido se o conceito de “orientação ao domínio” ainda não fosse estranho à maioria dos programadores.

O tempo passou e o modelo EJB começou a ser desprezado. Em aplicações cada vez mais web e cada vez menos dependentes de sistemas legados (i.e. orientados a dados) os programadores tentaram outras tecnologias de mais fácil implementação. Era o boom! dos frameworks. O mais importante foi a aplicação empresarial sem servidor JEE. O Spring com o seu mecanismo de injeção, O Struts com seu mecanismo de produtividade para controle Web e o Hibernate como seu mecanismo de persistência para todos os bancos tornavam o EJB, os padrões J2EE e toda a tecnologia EE obsuleta (quer dizer … evitável ). A remoticidade do EJB nunca pegou de fato em sistema simples. Ela é importante em sistema largamente distribuídos, fortemente transacionais e dependentes de legados coisa que um sistema web raramente é. A EJB, baseda em um paradigma diferente e incógnito até dos próprios idealizadores foi rotulada de complexa, pouco ágil e prolixa.

Isso mudou quando a especificação EJB 3 correu atrás de mudar a sua (má) fama e reformulou a forma como o programador tinha que escrever os Enterpise Beans. Por trás dos panos era a mesma coisa, mas pela frente um espetáculo completamente diferente. Junte-se a isso a popularidade do Hibernate e da especificação JPA e a idéia do JBoss Seams e temos um sistema usando o mesmo modelo do EJB original mas quase sem mexer com nenhuma API especial. Nasce o modelo desacoplado e o conceito de POJO (Plain Old Java Object – que quer significar: objeto Java livre de acoplamento com tecnologias ou frameworks especificos).

Mas mesmo assim, os programadores continuam pensando em termos de dados e bancos. A tecnologia mudou, mas o ciclo continua focado nos dados.

No meio disto, deu-se a renascença do paradigma de orientação a objetos (por oposição ao paradigma orientado a tecnologias). Isso foi facilitado pelo quase abandono da tecnologia EJB e pela popularização do manifesto da metodologia de desenvolvimento Domain Driven-Development (DDD, Desenvolvimento Orientado ao Domínio).

Este poderia ter sido o golpe final nos sistemas orientados a dados, mas não foi. O paradigma anterior ainda é tão poderoso que existem milhares de sistema orientados a dados pelo mundo a fora. Programadores que tentam enveredar por outros caminhos têm o seu caminho dificultado pelos fantasmas dos medos de um paradigma antigo. Mas por que a orientação ao domínio ainda não vingou?

Primeiro, porque muitos ainda pensam na orientação ao domínio como aquilo que a DDD prega. Sim, a DDD tem a sua base na orientação ao domínio, mas ela não é a orientação ao domínio per se . Em uma comparação simples: a filosofia de Kant é uma filosofia, não a filosofia. Da mesma forma a DDD é uma forma de ver e usar a orientação ao domínio, mas apenas uma das muitas.

Segundo, porque os padrões de implementação usados, e necessários nos tempos da EJB (pre-3) como o DAO e ou TO ainda são usados hoje em dia, mesmo quando vão contra o objetivo do sistema ou contra o modelo. Sistemas com múltiplos DAO mediando o ciclo de vida dos dados com o banco ( o real soberano do sistema) utilizando objetos de transferência – meros pacotes de dados glorificados – ainda são os símbolos icónicos do pensamento dos programadores e desenvolvedores. Mesmo quem diz seguir a DDD e a orientação ao domínio ainda os usa como guias para a sua implementação. E mesmo isto levando a distorções – quer dos padrões em si, quer da orientação ao domínio – estes programadores não se preocupam. Com base na idéia de que os fins justificam os meios, qualquer coisas pode ser chamada de qualquer nome e executar qualquer tarefa desde que isso resulte em um sistema que funcione. Como qualquer programador experiente saberá “funcionar” é o menor dos problemas. Programadores não escrevem código que funciona – isso qualquer IDE ou pessoa pode fazer com pouco ou nenhum treino. Programadores escrevem código que se entenda. Que seja facilmente extensível, alterável e útil.

Bom, mas afinal em que a orientação ao domínio é diferente? A primeira coisa é que a orientação ao domínio é, explicitamente, orientada a objetos. O objeto, não os dados, são o principal componente. Repare que os dados são 50% de um objeto: o estado. Os outros 50% – o comportamento – eram largamente espalhados pelos sistemas, resultando em código duplicado de difícil manutenção. Era esse o papel das procedures e dos triggers: serem o comportamento dos dados. O ciclo não está mais preocupado com o CRUD dos dados e sim com a manutenção do estado dos objetos (era isso que os Entity Beans pre-3 faziam). Aliás, nem há mais ciclo. Existe sim um fluxo de comandos (mensagens) entre objetos. Objetos se associam em camadas para prover níveis de acoplamento e encapsulamento diferente e a camada de domínio ganha destaque como o “cerebro” do sistema, a camada que sabe. TO não existem mais já que os próprios objetos têm os dados ‘dentro se si”. Manter os objetos significa implicitamente manter os dados e portanto os TO são dispensáveis. Ou, visto de outra forma, todos os objetos com estado são TO. Explicitá-los é uma tautologia.
Os objetos de serviço ganham o palco. Não são apenas mais uma forma de mexer ou acessar os dados, são eles mesmos cidadãos de primeira linha. Os mais populares, os serviços sem estado. Eles podem fazer qualquer coisa a qualquer momento. A tecnologia subjacente pode interceptar chamadas a eles e injetar capacidades de transação, controle de concorrência, segurança, logging, invocação remota, acoplamento com tencologias e protocolos especificos como CORBA ou SOAP – o que for necessário. O dominio é livre. Não depende de tecnologias, não depende de API, é portável e independente. Não está amarrado a nada nem a ninguém. Não mais DAOs para comunicar com o Banco de Dados. O rei vai nu. O soberano de outrora é agora escravo do domínio, um mero sistema de arquivos glorificado. Tanto o banco de dados perdeu relevância que virou comodity , onde antes era o centro do negócio.

Claro que ainda existem desafios técnicos em um sistema orientado ao domínio. Afinal os dados ainda existem e ainda os queremos preservar. A diferença é que eles não são mais o foco. O foco são os conceitos por detrás das regras do negócio, das “amarrações”. Estruturas de dados e não apena dados. Árvores, coleções, herança, polimorfismo , estratégias, mensagens, scritps dinâmicos, …

Em um sistema orientado ao domínio o comportamento merece o mesmo respeito e cuidado que os dados em si mesmos. A unificação dos dados e dos comportamentos em objetos. Objetos livres. Objetos que são o sistema. O resto é mero serviço de carpintaria e canalização.

Por que orientar o seu sistema a 50% do potencial da plataforma orientada a objetos? Não é isso um desperdício?

Anúncios

7 opiniões sobre “Dados vs Domínio”

  1. Na minha opinião isso (programadores que fazem código de qualquer jeito) ainda ocorre, porque principalmente no Brasil, muitas empresas pregam esse tipo de coisa, ou então preferem não apostar em desenvolvimento orientado ao domínio, talvez devido ao custo de colocar alguém “inteligente” para efetuar essa tarefa e passar isso para o restante da equipe. Mas com certeza é o modelo a ser seguido. Eu fiz o último sistema na empresa onde trabalho utilizando DDD e posso dizer que os benefícios são excelentes.

  2. Excelente texto muito bem colocado as suas observações, “Os objetos de serviço ganham o palco”, mas e os bastidores da origem dessas informações.

    Pensando em DDD, o que torna sustentável o processo Ágil com também as previsões ou falta do (requisitos-historicos)legado(dados-artefatos) que volta ao como um novo requisito tornando-se novamente útil ao domínio, onde teria essa recorrência ao paradigma destruindo user story(Scrum-Ágil) isso são artefados nesses artefados que não necessáriamente persistidos também entende-se como dados na sua observação isso não torno-se redundânte em preservar o paradigma ou mesmo sem solução ainda existente, por suas palavras “Em um sistema orientado ao domínio o comportamento merece o mesmo respeito e cuidado que os dados em si mesmos.”

  3. Interessante seu texto sergio, embora acho que a ordem de alguns fatos aconteceram por uma outra sequencia.

    Uma coisa que acho que ajuda bastante é ter um JUG que motive as pessoas, empresas e outras comunidades/associações destes cuidados.

    Eu tenho uma pergunta para você sergio, o que seria esperando por um programador em um projeto com DDD, visto que o programador conheça sobre o assunto ? (a intenção desta pergunta é saber quais as definições que o analista de negócio/sistema poderia contribuir para especificação e definições de projeto para o desenvolvedor. o que estou pensando seria no fluxo de trabalho)

  4. Sublinho que o artigo não é sobre DDD.
    Tentando responder diretamente à pergunta : a coisa processa-se (no meu entender) assim: um ou dois desenvolvedores conferenciam com o cliente/expert no dominio sobre as entidades, realações e mecanismos do dominio. O DDD tem como objetivo criar uma linguagem univoca que seja comum tanto ao cliente quanto aos desenvolvedores, etc… a todos no projeto. Então muito do trabalho é criar essa linguagem. Essa linguagem vira codigo naturalmente já que os conceitos são classificados nos diversos componentes do sistema OO.
    O modelo definido nas reuniões é implementado e testado. O resultado é apresentado ao cliente e uma nova rodada de conversações começa agora sobre outro aspecto do sistema. Provávelmente algum aspecto do modelo anterior será alterado pelas conversas futuras. O processo continua até que o sistema esteja pronto.
    DDD é intresecamente iterativo e interativo e se mistura bem com outras filosofias como TDD.

    Este processo do DDD acontece na fase de desenvolvimento e o foco é o dominio. Existe muito mais na aplicação que o dominio e por isso o DDD só abarca um pequena percentagem do sistema : o nucleo. É a parte mais importante e que mais interessa ao cliente ? Não necessáriamente. O Dominio é onde se traduzem requisitos funcionais. Existe uma mireade de requisitos não-funcionais em que o cliente também está interessado e que tb fazem parte do desenvolvimento.

  5. DDD é intresecamente iterativo e interativo e se mistura bem com outras filosofias como TDD.

    Eu penso que essas adoções é trabalhada de forma Ágil, ou seja o Domínio é estritamente o negócio do cliente, entretanto não se pensa em implementação é sim no que uso do sistema, uma OO refinada para resolver diretamente o que Objetiva o Domínio.

    Da questão Dados Vs Domínio, eles se coexistem de forma que o Domínio visa o caso de uso sua responsabilidade pelo negócio, enquanto que Dados vão ser granulidade ao sistema envolvido diante da implementação, e o FrameWork atual em questão.

  6. O buraco é mais em baixo. A diferença entre orientação a dados e orientação da dominio é conceptual. No fim tudo são dados. No fim tudo são beans. A diferença é como se encaram esses objetos. Quais as responsabilidades que eles têm e como eles cooperam com os outros objetos do sistema. Também em certa medida, a diferença define quem são esses outros objetos do sistema.

Deixe uma Resposta

Please log in using one of these methods to post your comment:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s