Domain Logic Patterns - fenix.tecnico.ulisboa.pt · É prática comum no tratamento da lógica de...
Transcript of Domain Logic Patterns - fenix.tecnico.ulisboa.pt · É prática comum no tratamento da lógica de...
Domain Logic PatternsDomain Logic Patterns
Pedro Lemos N.º [email protected]
Arquitecturas de Software 2004 - LEIC
Domain Logic Patterns
Arquitecturas de Software 2/3117 Novembro 2004
Outline da Apresentação
1. Introdução e Motivação de Padrões de Software
2. Padrões Arquitecturais para Aplicações Empresariais
3. Padrões de Lógica de DomínioTransaction ScriptDomain ModelTable ModuleService Layer
4. Conclusões
Domain Logic Patterns
Arquitecturas de Software 3/3117 Novembro 2004
Padrões de Software
Solução para um problema num determinado Solução para um problema num determinado contextocontexto
Uma forma estruturada de representarUma forma estruturada de representarinformação de informação de desenho desenho (por escrito e/ou diagramas)(por escrito e/ou diagramas)
Uma forma de comunicação de um Uma forma de comunicação de um expertexpert para um noviço para um noviço
A chave para perceber realmente o desenho OOA chave para perceber realmente o desenho OO
Mostrar Mostrar quandoquando e e comocomo aplicar as soluções aplicar as soluções
Domain Logic Patterns
Arquitecturas de Software 4/3117 Novembro 2004
Padrões de Software
Estes padrões aplicam-se Estes padrões aplicam-se nas diversas fases donas diversas fases dociclo de vida do software, especialmente ciclo de vida do software, especialmente nos diversos aspectosnos diversos aspectosdo processo de desenvolvimento de software.do processo de desenvolvimento de software.
Processo de Desenvolvimento
PadrõesPadrõesArquitecturaisArquitecturais
Padrões dePadrões deDesenhoDesenho
PadrõesPadrõesJ2EEJ2EE
PadrõesPadrõesOrganizacionaisOrganizacionais
Padrões dePadrões deAnáliseAnálise
PadrõesPadrõesSCMSCM
Internacio-Internacio-nalizaçãonalização
Domain Logic Patterns
Arquitecturas de Software 5/3117 Novembro 2004
Padrões Arquitecturais para Aplicações Empresariais
FowlerFowler apresenta vários padrões aplicáveis a apresenta vários padrões aplicáveis aarquitecturas empresariais de software (arquitecturas empresariais de software (J2EEJ2EE e e .NET.NET).).
Domain Logic PatternsDomain Logic Patterns
Data Source Architectural PatternsData Source Architectural Patterns
Object-Relational Behavioral PatternsObject-Relational Behavioral Patterns
Web Presentation PatternsWeb Presentation Patterns
Distribution PatternsDistribution Patterns
Concurrency PatternsConcurrency Patterns
Session State PatternsSession State Patterns
Domain Logic Patterns
Arquitecturas de Software 6/3117 Novembro 2004
Arquitectura baseada em 3 camadas primárias:Arquitectura baseada em 3 camadas primárias:
Presentation
Domain
Data Source
• Fornecimento de serviços• Apresentação de informação• Interacção com o utilizador
• Comunicação com BD• Gestão de transacções• Outras comunicações
• Lógica real do sistema
Arquitectura de referência
Domain Logic Patterns
Arquitecturas de Software 7/3117 Novembro 2004
Lógica de domínio
Cálculos baseados em Cálculos baseados em inputsinputs e informação persistente. e informação persistente.
Validação de dados provenientes da camada superiorValidação de dados provenientes da camada superior ( (ApresentaçãoApresentação).).
Determinação dos dados a enviar,Determinação dos dados a enviar, de acordo com os pedidos efectuados. de acordo com os pedidos efectuados.
Lógica de domínio ↔ Lógica de negócio
Domain Logic Patterns
Arquitecturas de Software 8/3117 Novembro 2004
Transaction Script
Aplicação a desenvolver assume-se Aplicação a desenvolver assume-se simples.simples.
Envolve pequenas porções de lógica.Envolve pequenas porções de lógica.
Equipa de desenvolvimento com escassos conhecimentosEquipa de desenvolvimento com escassos conhecimentosrelativos ao paradigma OO.relativos ao paradigma OO.
Transaction Script
Contexto do problema:
Domain Logic Patterns
Arquitecturas de Software 9/3117 Novembro 2004
Descrição
Organiza a lógica de negócio por Organiza a lógica de negócio por procedimentosprocedimentos..
Cada Cada procedimentoprocedimento trata uma determinada trata uma determinada acçãoacção do utilizador do utilizador (pedido proveniente da camada Apresentação). (pedido proveniente da camada Apresentação).
Processamento de Processamento de inputsinputs através de validações e cálculos. através de validações e cálculos.
FeedbackFeedback de dados à camada superior. de dados à camada superior.
Realização de chamadas directas à BD ou através de umRealização de chamadas directas à BD ou através de um wrapperwrapper simples. simples.
Regra geral, é codificado um Regra geral, é codificado um scriptscript/procedimento por cada/procedimento por cada transacção da BD. transacção da BD.
Domain Logic Patterns
Arquitecturas de Software 10/3117 Novembro 2004
Organização
Estruturação do código em módulos (metodologia clássica).Estruturação do código em módulos (metodologia clássica).
Organização dos Transaction Scripts
Vários Transaction Scripts numa única classe
Solução mais comum
Adequada à maioria dos casos
Cada Transaction Script na sua própria classe
Utilização do Padrão Comando
Manipulação de instâncias de scripts como objectos em tempo de execução
Raramento utilizado
Domain Logic Patterns
Arquitecturas de Software 11/3117 Novembro 2004
Vantagens e Desvantagens
Modelo simples acessível à esmagadora maioria dos Modelo simples acessível à esmagadora maioria dos developersdevelopers..
Interacção simplificada com a camada inferior.Interacção simplificada com a camada inferior.
Limites da transacção bem definidos (iniciar/confirmar transacção).Limites da transacção bem definidos (iniciar/confirmar transacção).
Evidenciam-se com o aumento da complexidade da lógica.Evidenciam-se com o aumento da complexidade da lógica.
Origina porções de código duplicado de díficil detecção.Origina porções de código duplicado de díficil detecção.
Difícil de manter uma estrutura sólida e robusta.Difícil de manter uma estrutura sólida e robusta.
Vantagens:
Desvantagens:
Domain Logic Patterns
Arquitecturas de Software 12/3117 Novembro 2004
Domain Model
Regras de negócio complexas e dinâmicas queRegras de negócio complexas e dinâmicas queapresentam diferentes tipos de comportamento.apresentam diferentes tipos de comportamento.
Envolvem validação de dados, cálculosEnvolvem validação de dados, cálculose derivações complexas.e derivações complexas.
Complexidade inerente ao próprio âmbito da aplicação.Complexidade inerente ao próprio âmbito da aplicação.
Domain Model
Contexto do problema:
Domain Logic Patterns
Arquitecturas de Software 13/3117 Novembro 2004
Descrição
Essência do paradigma OO.Essência do paradigma OO.
Um objecto Um objecto Domain-ModelDomain-Model pode incorporar pode incorporardados e comportamento.dados e comportamento.
Pode-se classificar os objectos em: objectos que capturamPode-se classificar os objectos em: objectos que capturaminformaçãoinformação e objectos que implementam as e objectos que implementam as regras de negócioregras de negócio..
Cada objecto contém toda a lógica associada a si mesmo.Cada objecto contém toda a lógica associada a si mesmo.
Reunir todo o comportamento com uma determinadaReunir todo o comportamento com uma determinadaespecificidade no mesmo objecto.especificidade no mesmo objecto.
Criação de uma rede de objectos interligados na qual cada objectoCriação de uma rede de objectos interligados na qual cada objectorepresenta uma entidade concreta e objectiva.representa uma entidade concreta e objectiva.
Domain Logic Patterns
Arquitecturas de Software 14/3117 Novembro 2004
Divisão em estilos
Semelhante ao desenho de BD
Correspondência unívoca entre um objecto de domínio e uma tabela da BD
Associado ao padrão Active Record
Pode divergir do desenho de BD
Utiliza herança, estratégias e padrões de desenho
Resulta na criação de redes complexas de pequenos objectos interligados
Associado ao padrão Data Mapper
Modelo de domínio simples Modelo de domínio denso
Domain Logic Patterns
Arquitecturas de Software 15/3117 Novembro 2004
Vantagens e Desvantagens
Existência de inúmeras técnicas que permitem dar resposta aExistência de inúmeras técnicas que permitem dar resposta aincrementos de complexidade lógica de forma bem organizada.incrementos de complexidade lógica de forma bem organizada.
Adaptação à metodologia OO conduz à escolha incondicionalAdaptação à metodologia OO conduz à escolha incondicionaldeste padrão, mesmo em aplicações relativamente simples.deste padrão, mesmo em aplicações relativamente simples.
Necessária experiência em modelos Necessária experiência em modelos densosdensos de objectos. de objectos.
Nem todos os Nem todos os developersdevelopers atingem o patamar exigido pelo modelo. atingem o patamar exigido pelo modelo.
Pesquisa difícil de comportamento espalhadoPesquisa difícil de comportamento espalhadopelos diversos objectos.pelos diversos objectos.
Mapeamento do Mapeamento do Domain ModelDomain Model para uma BD é sempre complicado. para uma BD é sempre complicado.
Vantagens:
Desvantagens:
Domain Logic Patterns
Arquitecturas de Software 16/3117 Novembro 2004
Exemplos
Transaction Script
Domain Model
Domain Logic Patterns
Arquitecturas de Software 17/3117 Novembro 2004
Table Module
Similar ao contexto do Similar ao contexto do Domain ModelDomain Model
Interface / Mapeamento com uma base de dados relacionalInterface / Mapeamento com uma base de dados relacionalproblemático e de difícil implementaçãoproblemático e de difícil implementação
Table Module
Contexto do problema:
Domain Logic Patterns
Arquitecturas de Software 18/3117 Novembro 2004
Descrição
Organiza a lógica recorrendo à filosofia:Organiza a lógica recorrendo à filosofia: Uma classe por tabela da BDUma classe por tabela da BD..
Cada instância de uma classe contém vários procedimentos queCada instância de uma classe contém vários procedimentos queactuam sobre os dados.actuam sobre os dados.
Permite unificar dados e comportamento, e simultaneamentePermite unificar dados e comportamento, e simultaneamentemanter as forças de um modelo relacional.manter as forças de um modelo relacional.
A cardinalidade de A cardinalidade de Table ModulesTable Modules não tem que ser não tem que sernecessariamente igual ao número de tabelas da BD.necessariamente igual ao número de tabelas da BD.
Tabelas virtuais: Vistas perceptíveis e Tabelas virtuais: Vistas perceptíveis e queriesqueries..
Domain Logic Patterns
Arquitecturas de Software 19/3117 Novembro 2004
Padrões relacionados
Table Data Gateway Funciona como um gateway para uma tabela da BD.Funciona como um gateway para uma tabela da BD. Uma instância trata de todas as linhas da tabela.Uma instância trata de todas as linhas da tabela.
Alternativa ao uso de Alternativa ao uso de factory methodsfactory methods para a realização de para a realização de queriesqueries..
Record Set Representação em memória de dados relacionais.Representação em memória de dados relacionais. Utilizado em ambientes onde existeUtilizado em ambientes onde existe
uma forma comum de manipular informação.uma forma comum de manipular informação.
Table ModuleTable Module fornece interface explícita fornece interface explícita que actua sobre o que actua sobre o Record SetRecord Set..
Domain Logic Patterns
Arquitecturas de Software 20/3117 Novembro 2004
Vantagens e Desvantagens
Enquadra-se bem no resto da arquitectura de software.Enquadra-se bem no resto da arquitectura de software.
Estrutura sólida e de fácil detecção e remoção de código duplicado.Estrutura sólida e de fácil detecção e remoção de código duplicado.
Encapsulamento de comportamento e dados.Encapsulamento de comportamento e dados.
Impossibilidade de usar técnicas de estruturação OO:Impossibilidade de usar técnicas de estruturação OO: Herança, polimorfismo, relações instância-para-instância, Herança, polimorfismo, relações instância-para-instância, outros padrões OO. outros padrões OO.
Vantagens:
Desvantagens:
Domain Logic Patterns
Arquitecturas de Software 22/3117 Novembro 2004
Decisões
Este gráfico não é Este gráfico não é estáticoestático nem nem absolutoabsoluto!!Sujeito a factores externos, Sujeito a factores externos, exex: familiarização da equipa de : familiarização da equipa de
desenvolvimento com um determinado padrão.desenvolvimento com um determinado padrão.
Domain Logic Patterns
Arquitecturas de Software 23/3117 Novembro 2004
Introdução ao Service Layer
Service Layer
Domain Model
Data SourceLayer
É prática comum no tratamento daÉ prática comum no tratamento dalógica de domíniológica de domínio a divisão em duas a divisão em duas camadas:camadas:
Service LayerService Layer
Domain ModelDomain Model ou ou Table ModuleTable Module
Domain Logic Patterns
Arquitecturas de Software 24/3117 Novembro 2004
Descrição
Define um conjunto de operações dirigidas àsDefine um conjunto de operações dirigidas às camadas de interface com o utilizador. camadas de interface com o utilizador.
Providencia uma API simples e completa.Providencia uma API simples e completa.
Local ideal para Local ideal para controlo de transacçõescontrolo de transacções e e medidas de segurançamedidas de segurança..
Coordenação de respostas aos pedidos requeridos.Coordenação de respostas aos pedidos requeridos.
Domain Logic Patterns
Arquitecturas de Software 25/3117 Novembro 2004
Implementações
Conjunto de facades leves sobre um Domain Model.
Facades não implementam lógica de negócio.
Service Layer faz o reencaminhamento de pedidos nas facades para os objectos de baixo nível.
API do Service Layer é de simples utilização, visto que é tipicamente orientada em redor de casos de uso.
A lógica de negócio é implementada recorrendo a scripts.
Cada classe constitui um “Serviço”.
Os objectos de domínio de base são muito simples(Estilo Domain Model simples).
Domain Facade Operation Script
Domain Logic Patterns
Arquitecturas de Software 26/3117 Novembro 2004
Baseia-se numa distribuição de comportamento.
Colocar lógica respeitante a uma dada transacção ou caso de uso num Transaction Script(controlador de caso de uso).
Comportamento partilhado por dois ou mais casos de uso é colocado em objectos de domínio(entidades).
Estilo Controlador-Entidade
Implementações
Domain Logic Patterns
Arquitecturas de Software 27/3117 Novembro 2004
Considerações
Classes de um Classes de um Service LayerService Layer são adequadas à invocação remota. são adequadas à invocação remota.
CustoCusto: Distribuição de objectos: Distribuição de objectos(especialmente tendo um (especialmente tendo um Domain ModelDomain Model complexo e uma UI complexo e uma UI densadensa))
Adicionar acesso remoto apenas quando for necessárioAdicionar acesso remoto apenas quando for necessárioatravés do uso de através do uso de Remote FacadesRemote Facades..
Invocação remota
As operações são normalmente determinadas pelasAs operações são normalmente determinadas pelasnecessidades das camadas superioresnecessidades das camadas superiores(sendo a mais significativa a interacção com o utilizador).(sendo a mais significativa a interacção com o utilizador).
Correspondência 1-para-1 entre casos de uso “CRUD”Correspondência 1-para-1 entre casos de uso “CRUD”e operações de e operações de Service LayerService Layer..
Identificação de serviços/operações
Domain Logic Patterns
Arquitecturas de Software 28/3117 Novembro 2004
Adequação do padrão
Aplicação com diversos tipos de clientes para a lógica de negócio.Aplicação com diversos tipos de clientes para a lógica de negócio.
Respostas complexas.Respostas complexas.
Casos de uso que envolvem múltiplos recursos transaccionais.Casos de uso que envolvem múltiplos recursos transaccionais.
Aplicação com apenas um tipo de cliente (ex: UI bem definida).Aplicação com apenas um tipo de cliente (ex: UI bem definida).
Recurso transaccional unitário.Recurso transaccional unitário.
Quando usar:
Quando não usar:
Domain Logic Patterns
Arquitecturas de Software 29/3117 Novembro 2004
Conclusões
Há diversas formas de organizar lógica de domínio.Há diversas formas de organizar lógica de domínio.
Transaction ScriptTransaction Script – – Abordagem simplista com filosofia:Abordagem simplista com filosofia: “Um procedimento por acção”. “Um procedimento por acção”.
Domain ModelDomain Model – “Descreve todos os tipos de objecto de domínio – “Descreve todos os tipos de objecto de domínioe as relações entre as suas instâncias, que colectivamentee as relações entre as suas instâncias, que colectivamentedescrevem o espaço de domínio.” [Timothy Howard]descrevem o espaço de domínio.” [Timothy Howard]
Table ModuleTable Module – Abordagem orientada ao modelo relacional: – Abordagem orientada ao modelo relacional: “Uma classe por tabela da BD”. “Uma classe por tabela da BD”.
Service LayerService Layer – Combina o uso de procedimentos e – Combina o uso de procedimentos eobjectos de domíno, tentando incorporar as qualidades de ambos.objectos de domíno, tentando incorporar as qualidades de ambos.
Domain Logic Patterns
Arquitecturas de Software 31/3117 Novembro 2004
Bibliografia
M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, and R. Stafford, M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, and R. Stafford, Patterns of Enterprise Application ArchitecturePatterns of Enterprise Application Architecture.. Addison-Wesley, 2002.Addison-Wesley, 2002.
Erich Gamma, et. al., Erich Gamma, et. al., Design Patterns: Elements of Reusable Object-Design Patterns: Elements of Reusable Object-Oriented SoftwareOriented Software. Addison-Wesley, 1995.. Addison-Wesley, 1995.
Eric Evans, Eric Evans, Domain-Driven Design: Tackling Complexity in the HeartDomain-Driven Design: Tackling Complexity in the Heartof Softwareof Software. Addison-Wesley, 2003.. Addison-Wesley, 2003.