Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Arquitetura de Software - Performance, Layers e Domain Layer

3,725 views

Published on

Para mais detalhes, visite http://blog.bluesoft.com.br/tag/andre-faria/

Published in: Technology, Business

Arquitetura de Software - Performance, Layers e Domain Layer

  1. 1. Arquitetura de SoftwarePerformance, Layers e Domain LayerAndré Faria Gomes@andrefaria
  2. 2. Conceitos dePerformance
  3. 3. Tempo de Resposta Tempo de processamento de uma requisição externa 2 segundos
  4. 4. Responsividade Tempo de reação a uma requisição 100 Ms
  5. 5. Latência Tempo mínimo para qualquer requisição, mesmo nula500 Ms
  6. 6. ThroughputQuanto pode ser feitoem um dado intervalo de tempo1588 bytes/segundo900 transações/minuto
  7. 7. Carga Stress suportado por um sistema,geralmente medido em número de usuários.5000 usuários
  8. 8. Sensibilidade a Carga Variação do tempo de resposta em relação a carga
  9. 9. Performance Eficiência dividida pelos recursosUm sistema que realiza 50 transações em 1CPU é melhor do que que faz 80 com 2.
  10. 10. Escalabilidade O quanto adicionar recursos(hardware) afeta a performance?
  11. 11. Horizontal Melhorar recursos da máquinaVertical Aumentar o número de servidores
  12. 12. PadrõesSão propostas desoluções para um problemas que comuns.
  13. 13. Layers
  14. 14. Divisão Conceitual Você pode criar um serviço Ftp sem compreender Tcp
  15. 15. Isolamento Você pode alterar umcamada sem afetar as outras
  16. 16. SubstituiçãoSubstituir 1 camada sem modificar outras
  17. 17. Layer != Tier Tier Divisão Física (Client/Server) Layer Divisão Lógica(que também poderia ser física)
  18. 18. CamadasApresentação Domínio Database Interação Regras de Comunicação do Software Negócio, com outroscom o Usuário Cálculos e sistemas e ou Serviço Validações Persistência Cliente
  19. 19. As camadas de domínio e dados não devem ser dependentes da apresentação. Fowler
  20. 20. O que aconteceria se vocêtivesse que substituir seu banco de dados por um arquivo XML?
  21. 21. E se tivesse que criar um cliente para iPhone ao invés de HTML?
  22. 22. Regras de Negócio
  23. 23. 3 Abordagens Transaction Scripts Domain Model Table Module
  24. 24. Transaction Script
  25. 25. Um procedimento que recebedados 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. 26. Um procedimento único para cada açãodo Usuário Pode ser separado em sub-rotinas e que podem ser compartilhadas por diferentes scripts.
  27. 27. Vantagens
  28. 28. FácilA maioria dos desenvolvedores entende
  29. 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. 30. Funciona bem com umacamada de dados simplescomo Row Gateway ou Table Data Gateway
  31. 31. nt ag e nsDes vaSurgem a medida que a complexidade das regras de negócio aumentam, principalmenteduplicidade de código e falta de legibilidade
  32. 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. 33. Table Module É o meiotermo entre o Domain Model eTransaction Scripts.
  34. 34. Possui apenas 1 instancia por tabela ou view que gerencia toda a regra de negócio.
  35. 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. 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. 37. Domain Model
  38. 38. É a essência do paradigma OO. Cada objeto contém uma parte da lógica, do comportamento relevante a ele.Objetos
  39. 39. Estrutura a complexidade de forma organizada
  40. 40. DataMapperLigação entre os objetos do domínio e as tabelas dobanco de dados
  41. 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. 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. 43. ServiceLayer
  44. 44. Divisão Uma abordagem comum que divide a camada de domínio em duas.
  45. 45. API A camada deapresentação interagecom o domínio apenas através do ServiceLayer que atua como uma API da aplicação
  46. 46. Service Excelente para inserirSegurança e Controle de Transações. Recomendável queaja como um Façade sem comportamento próprio.
  47. 47. Regras de NegócioDomain Model Controller-Entity Apenas Style Transaction Segurança e Comportament ScriptTransações no o comum emService Layer, objetos, AnemicComportament específico em Domain o todo no transaction ModelDomain Model scripts.Domain Service
  48. 48. “Minha preferência é porter a Service Layer mais magra que for possível” Martin Fowler
  49. 49. Referências http:// www.thedeveloperday.com/ domain-model-logic-patterns/ http://martinfowler.com/ eaaCatalog/

×