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     SoftwarePerformance, Layers e Domain LayerAndré Faria Gomes@andrefaria
Conceitos dePerformance
Tempo de Resposta         Tempo de      processamento de       uma requisição           externa      2 segundos
Responsividade   Tempo de reação a    uma requisição            100 Ms
Latência   Tempo mínimo para   qualquer requisição,      mesmo nula500 Ms
ThroughputQuanto pode ser feitoem um dado intervalo     de tempo1588 bytes/segundo900 transações/minuto
Carga Stress suportado por um sistema,geralmente medido  em número de     usuários.5000 usuários
Sensibilidade a   Carga      Variação do        tempo de      resposta em    relação a carga
Performance                         Eficiência  dividida pelos     recursosUm sistema que realiza 50 transações em 1CPU é ...
Escalabilidade  O quanto adicionar recursos(hardware) afeta a performance?
Horizontal  Melhorar recursos da máquinaVertical  Aumentar o número de servidores
PadrõesSão propostas desoluções para um  problemas que     comuns.
Layers
Divisão Conceitual Você pode criar um  serviço Ftp sem  compreender Tcp
Isolamento Você pode alterar umcamada sem afetar as        outras
SubstituiçãoSubstituir 1 camada sem modificar outras
Layer != Tier      Tier Divisão Física       (Client/Server)     Layer Divisão Lógica(que também poderia ser física)
CamadasApresentação Domínio         Database   Interação    Regras de    Comunicação  do Software   Negócio,      com outr...
As camadas de domínio e dados não devem ser     dependentes da     apresentação.                    Fowler
O que aconteceria se vocêtivesse que substituir seu banco de dados por um    arquivo XML?
E se tivesse que criar  um cliente para iPhone ao invés de     HTML?
Regras de Negócio
3 Abordagens    Transaction Scripts     Domain Model      Table Module
Transaction Script
Um procedimento que recebedados da camada de apresentação,    processa com validações e cálculos, armazena no banco de   d...
Um procedimento único     para cada açãodo Usuário  Pode ser separado  em sub-rotinas e    que podem ser compartilhadas po...
Vantagens
FácilA maioria dos desenvolvedores entende
Bom com Transações         Bom para definir limites de           transações. É fácil usar           ferramentas para trata...
Funciona bem com umacamada de dados simplescomo Row Gateway ou Table Data Gateway
nt ag e nsDes vaSurgem a medida que a complexidade das  regras de negócio     aumentam,    principalmenteduplicidade de có...
1. class Hotel  2. {  3.     public function __construct(Data_Access_Gateway gateway)  4.     {  5.         this->_gateway...
Table Module  É o meiotermo entre o   Domain   Model eTransaction   Scripts.
Possui apenas 1 instancia por tabela ou view que gerencia   toda a regra de negócio.
class Hotel  {      public Hotel(DataAccessGateway gateway, Booking booking) {          this.gateway = gateway        this...
class Booking {       def gateway    public Booking(DataAccessGateway gateway) {          this.gateway = gateway      }   ...
Domain Model
É a essência do paradigma OO. Cada objeto contém uma parte da lógica, do comportamento                 relevante a ele.Obj...
Estrutura a complexidade de forma organizada
DataMapperLigação entre os objetos do domínio e as  tabelas dobanco de dados
class Hotel {      def hotelId    def rooms       public def bookRoom(user, fromDate, toDate)      {          room = getRo...
class Room {      def roomId    def bookings = []      public def bookRoom(user, fromDate, toDate) {          days = getAm...
ServiceLayer
Divisão     Uma abordagem comum que divide a       camada de domínio em duas.
API    A camada deapresentação interagecom o domínio apenas  através do ServiceLayer que atua como   uma API da      aplic...
Service Excelente para inserirSegurança e Controle de     Transações.  Recomendável queaja como um Façade sem comportament...
Regras de NegócioDomain Model     Controller-Entity   Apenas             Style          Transaction Segurança e     Compor...
“Minha preferência é porter a Service Layer mais magra que for possível”    Martin Fowler
Referências  http://  www.thedeveloperday.com/  domain-model-logic-patterns/  http://martinfowler.com/  eaaCatalog/
Arquitetura de Software - Performance, Layers e Domain Layer
Upcoming SlideShare
Loading in …5
×

Arquitetura de Software - Performance, Layers e Domain Layer

3,709 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/

×