Advertisement

Arquitetura de Software - Performance, Layers e Domain Layer

CEO @Bluesoft (Retail Cloud SaaS ERP), Investor @Wow, Mentor @LigaVentures at Bluesoft Sistemas
May. 2, 2011
Advertisement

More Related Content

Advertisement

Recently uploaded(20)

Arquitetura de Software - Performance, Layers e Domain Layer

  1. Arquitetura de Software Performance, Layers e Domain Layer André Faria Gomes @andrefaria
  2. Conceitos de Performance
  3. Tempo de Resposta Tempo de processamento de uma requisição externa 2 segundos
  4. Responsividade Tempo de reação a uma requisição 100 Ms
  5. Latência Tempo mínimo para qualquer requisição, mesmo nula 500 Ms
  6. Throughput Quanto pode ser feito em um dado intervalo de tempo 1588 bytes/segundo 900 transações/minuto
  7. Carga Stress suportado por um sistema, geralmente medido em número de usuários. 5000 usuários
  8. Sensibilidade a Carga Variação do tempo de resposta em relação a carga
  9. Performance Eficiência dividida pelos recursos Um sistema que realiza 50 transações em 1 CPU é melhor do que que faz 80 com 2.
  10. Escalabilidade O quanto adicionar recursos (hardware) afeta a performance?
  11. Horizontal Melhorar recursos da máquina Vertical Aumentar o número de servidores
  12. Padrões São propostas de soluções para um problemas que comuns.
  13. Layers
  14. Divisão Conceitual Você pode criar um serviço Ftp sem compreender Tcp
  15. Isolamento Você pode alterar um camada sem afetar as outras
  16. Substituição Substituir 1 camada sem modificar outras
  17. Layer != Tier Tier Divisão Física (Client/Server) Layer Divisão Lógica (que também poderia ser física)
  18. Camadas Apresentação Domínio Database Interação Regras de Comunicação do Software Negócio, com outros com o Usuário Cálculos e sistemas e ou Serviço Validações Persistência Cliente
  19. As camadas de domínio e dados não devem ser dependentes da apresentação. Fowler
  20. O que aconteceria se você tivesse que substituir seu banco de dados por um arquivo XML?
  21. E se tivesse que criar um cliente para iPhone ao invés de HTML?
  22. Regras de Negócio
  23. 3 Abordagens Transaction Scripts Domain Model Table Module
  24. Transaction Script
  25. Um procedimento que recebe dados da camada de apresentação, processa com validações e cálculos, armazena no banco de dados, e invoca operações de outros sistemas, então replica mais dados para a apresentação
  26. Um procedimento único para cada ação do Usuário Pode ser separado em sub-rotinas e que podem ser compartilhadas por diferentes scripts.
  27. Vantagens
  28. FácilA maioria dos desenvolvedores entende
  29. Bom com Transações Bom para definir limites de transações. É fácil usar ferramentas para tratar transações por trás dos panos.
  30. Funciona bem com uma camada de dados simples como Row Gateway ou Table Data Gateway
  31. nt ag e ns Des va Surgem a medida que a complexidade das regras de negócio aumentam, principalmente duplicidade de código e falta de legibilidade
  32. 1. class Hotel   2. {   3.     public function __construct(Data_Access_Gateway gateway)   4.     {   5.         this->_gateway = gateway;   6.     }     7.    8.     public function bookRoom(userId, fromDate, toDate)   9.     {   10.         roomId = this->_gateway->_getRoomIdBetweenDates(dateFrom, dateTo);     11.    12.         if (!roomId) {   13.             return false;   14.         }     15.    16.         days = this->_getAmountOfDays(fromDate, toDate);     17.    18.         if (days < = 7) {   19.             price = days * 100;   20.         } else {   21.             price = days * 80;   22.         }   23.    24.         data = array(   25.             'userId' => userId,   26.             'roomId' => roomId,   27.             'fromDate' => fromDate,   28.             'toDate' => toDate,   29.             'price' => price,   30.         );     31.    32.         bookingId = this->_gateway->insert('bookings', data);     33.    34.         return bookingId;   35.     }   36. }  
  33. Table Module É o meio termo entre o Domain Model e Transaction Scripts.
  34. Possui apenas 1 instancia por tabela ou view que gerencia toda a regra de negócio.
  35. class Hotel  {       public Hotel(DataAccessGateway gateway, Booking booking) {           this.gateway = gateway         this. booking = booking     }            public def bookRoom(userId, fromDate, toDate) {           roomId = booking.getRoomBetweenDates(fromDate, toDate)            if (!roomId) {               return false         }                days = getAmountOfDays(fromDate, toDate);                if (days < = 7) {               price = days * 100         } else {               price = days * 80           }              bookingId = booking.addBooking(userId, roomId, fromDate, toDate, price)     }   }  
  36. class Booking {   def gateway     public Booking(DataAccessGateway gateway) {           this.gateway = gateway       }          public def getRoomBetweenDates(dateFrom, dateTo) {           return gateway.getRoomBetweenDates(dateFrom, dateTo)     }          public def addBooking(userId, roomId, fromDate, toDate, price) {           data = [               'userId' : userId,               'roomId' : roomId,               'fromDate': fromDate,               'toDate' : toDate,               'price' : price,           ]            bookingId = gateway.insert('bookings', data)        }   } 
  37. Domain Model
  38. É a essência do paradigma OO. Cada objeto contém uma parte da lógica, do comportamento relevante a ele. Objetos
  39. Estrutura a complexidade de forma organizada
  40. DataMapper Ligação entre os objetos do domínio e as tabelas do banco de dados
  41. class Hotel {       def hotelId     def rooms         public def bookRoom(user, fromDate, toDate)       {           room = getRoomBetweenDates(fromDate, toDate);              if (!room) {               return false;           }                booking = room.bookRoom(user, fromDate, toDate);       }   }  
  42. class Room {       def roomId     def bookings = []        public def bookRoom(user, fromDate, toDate) {           days = getAmountOfDays(fromDate, toDate)            if (days < = 7) {               booking =  new Booking(user, new ShortBookingStrategy(user, days))         } else {               booking =  new Booking(user, new NormalBookingStrategy(user, days))         }             return booking       }   }  
  43. Service Layer
  44. Divisão Uma abordagem comum que divide a camada de domínio em duas.
  45. API A camada de apresentação interage com o domínio apenas através do Service Layer que atua como uma API da aplicação
  46. Service Excelente para inserir Segurança e Controle de Transações. Recomendável que aja como um Façade sem comportamento próprio.
  47. Regras de Negócio Domain Model Controller-Entity Apenas Style Transaction Segurança e Comportament Script Transações no o comum em Service Layer, objetos, Anemic Comportament específico em Domain o todo no transaction Model Domain Model scripts. Domain Service
  48. “Minha preferência é por ter a Service Layer mais magra que for possível” Martin Fowler
  49. Referências http:// www.thedeveloperday.com/ domain-model-logic-patterns/ http://martinfowler.com/ eaaCatalog/
Advertisement