Arquitetura e padrões de software

Apresentação em tema: "Arquitetura e padrões de software"— Transcrição da apresentação:

1 Arquitetura e padrões de software
Eduardo Bezerra (CEFET/RJ)

2 Créditos Apresentação baseada no livro a seguir. Martin Fowler
Martin Fowler, Padrões de Arquitetura de Aplicações Corporativas, Porto Alegre: Bookman, 2006. Martin Fowler

3 Padrões para Organização da Lógica do Domínio
Prof. Eduardo Bezerra

4 Sumário Padrões para organizar a lógica do domínio Conclusões
Roteiro de Transação (Transaction Script) Módulo Tabela (Table Module) Modelo de Domínio (Domain Model) Modelo de Domínio Anêmico (Anemic Domain Model) Camada de Serviço (Service Layer) Conclusões

5 Relação com a camada da aplicação

6 Introdução A camada da domínio é responsável pela inteligência da aplicação, e.g., regras de negócio, algoritmos de cálculo relativos aos processos, etc. Existem três padrões principais: Transaction Script, Table Module, Domain Model. Adicionalmente, o padrão Service Layer pode ser usado em circunstâncias específicas.

7 Roteiro de transação (Transaction Script)

8 Roteiro de Transação Transaction Script: “Organizes business logic by procedures where each procedure handles a single request from the presentation layer.” –Martin Fowler Cada transação é uma função, que faz chamadas diretas ao banco de dados, ou através de uma API simples (thin database wrapper). Embora cada transação tenha seu próprio TS, atividades comuns a vários roteiros podem ser fatoradas em subrotinas.

9 Roteiro de Transação Fonte:

10 Roteiro de Transação Vantagem: fácil de implementar. Desvantagem:
Potencial para duplicação de código. Não adequado para lógica de domínio complexa. Fonte:

11 Roteiro de Transação Fonte: FOWLER - PofEAA

12 Módulo tabela (Table Module)

13 Módulo Tabela Table Module: “A single instance that handles the business logic for all rows in a database table or view.” –Martin Fowler Nessa abordagem, a lógica do domínio é organizada de tal forma a refletir a estrutura do banco de dados. Cada tabela do BD está associada a uma classe TM, que possui funções para realizar operações sobre os dados daquela tabela. Cada classe TM contém lógica do domínio associada aos dados de sua tabela correspondente.

14 Módulo Tabela Esta alternativa “está no meio caminho” entre as abordagens Roteiro de Transação e Modelo de Domínio. Organizar a lógica do domínio em torno das tabelas do BD fornece uma estruturação melhor do que organizar essa lógica usando procedimentos. Contudo, essa abordagem não pode usar toda a força do paradigma OO na implementação (herança, polimorfismo, padrões GoF, etc).

15 Módulo Tabela Usado em .NET, por conta do suporte fornecido pela plataforma. Componentes Dataset, DataTable, DataRow, etc. Essa abordagem é similar ao Roteiro de Transação, portanto as vantagens e desvantagens também são similares. Particularidades: Pode manipular situações mais complexas que o Roteiro de Transação. Não tão escalável quanto o Modelo de Domínio.

16 Módulo Tabela

17 Módulo Tabela Fonte:

18 Módulo Tabela Fonte: FOWLER - PofEAA

19 Módulo Tabela O Módulo Tabela usa um RecordSet, que é uma representação, em memória principal, de dados tabulares. e.g., DataSet no ADO.NET e RowSet do JDBC 2.0. Fonte: FOWLER - PofEAA

20 Modelo de Domínio (Domain Model)

21 Modelo de Domínio “A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual concept, whether as large as a corporation or as small as a single line on an order form.” –Martin Fowler Essa abordagem de organização envolve implementar as classes conceituais. É a abordagem mais OO de todas. Consistente com DDD. DDD = domain driven design.

22 Modelo de Domínio Vantagem: flexível e adequado a situações em que a lógica do domínio é complexa. Muitos objetos interconectados Muitas regras do negócio Desvantagem: muito trabalho de mapeamento e para isolar o modelo de domínio de aspectos técnicos (persistência, apresentação, transações, etc.) Descasamento de impedância: modelos OO e relacional organizam dados de formas distintas.

23 Modelo de Domínio Fonte:

24 Modelo de Domínio Anêmico
É um anti-padrão (anti-pattern). Se assemelha ao Domain Model, pois possui uma estrutura de objetos rica como este último. Entretanto, lógica do domínio é tipicamente controlada por um TS, com os objetos do modelo servindo de contêineres de dados.

25 Modelo de Domínio Anêmico
Fonte:

26 Modelo de Domínio Anêmico
Num modelo OO, temos representações dos conceitos que estamos modelando na forma de classes. Ao utilizar o modelo de programação com objetos anêmicos, dividimos o domínio em “classes de dados” e “classes de lógica”. Classes de dados: atributos mais getters e setters! Isso é uma violação de dois princípios importantes da OO, encapsulamento e coesão. Retorno à programação procedimental!

27 Modelo de Domínio Anêmico
Vantagem: semelhante a TS  simplicidade. Desvantagens: Não conformidade com relação aos princípios do encapsulamento e da coesão.

28 Modelos Anêmicos versus Modelos Ricos
Fonte das figuras:

29 Camada de serviço (service layer)

30 Camada de Serviço Uma abordagem comum para lidar com a lógica de domínio é definir uma camada designada Service Layer sobreposta a outra camada, com Domain Model ou Table Module. Esta abordagem não faz sentido com Transaction Script. Este padrão define as fronteiras de uma aplicação com uma camada de serviços que estabelece uma série de operações e coordena a resposta da aplicação em cada operação. As operações de sistemas são alocadas nessa camada. Esta abordagem não faz sentido com Transaction Script pois a baixa complexidade não o justifica.

31 Camada de Serviço “Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.” Fonte:

32 Conclusões

33 Resumo Formas de organizar a lógica do domínio: Transaction Script
Table Module Domain Model Service Layer

34 Conclusões Na prática, é possível que aplicações usem uma mistura dos padrões aqui apresentados durante a organização de lógica do domínio. Nenhum dos padrões descritos aqui é adequado para todas as situações. A escolha do padrão adequado depende do contexto. Particularmente, depende da complexidade da lógica do domínio do sistema a ser desenvolvido.

35 Conclusões Fonte: FOWLER - PofEAA
Note que o Domain Model é o padrão que melhor acomoda incrementos na complexidade da lógica de negócio. O Transaction Script, pelo contrário apresenta um limite para o qual é impossível introduzir mais complexidade. É importante compreender até que ponto poderá a lógica de negócio aumentar de complexidade dado que numa fase mais adiantada de um projeto pode ser demasiado tarde para voltar para trás. Por outro lado, não faz sentido estruturar um problema de complexidade garantidamente baixa com um padrão tão rico como o Domain Model. Fonte: FOWLER - PofEAA

36 Referências

37 Referências Anemic Domain Model. Martin Fowler. Why getter and setter methods are evil. Allen Holub toolbox.html Tell, don’t ask. The Pragmatic Programmers.