Arquitetura de
     Software
Performance, Layers e Domain Layer



André Faria Gomes
@andrefaria
Conceitos de
Performance
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 nula


500 Ms
Throughput
Quanto pode ser feito
em um dado intervalo
     de tempo
1588 bytes/segundo
900 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
     recursos

Um sistema que realiza
 50 transações em 1
CPU é melhor do que
 que faz 80 com 2.
Escalabilidade
  O quanto adicionar recursos
(hardware) afeta a performance?
Horizontal
  Melhorar recursos da máquina

Vertical
  Aumentar o número de servidores
Padrões
São propostas de
soluções para um
  problemas que
     comuns.
Layers
Divisão Conceitual
 Você pode criar um
  serviço Ftp sem
  compreender Tcp
Isolamento
 Você pode alterar um
camada sem afetar as
        outras
Substituição
Substituir 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)
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
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 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
Um procedimento único
     para cada ação
do Usuário

  Pode ser separado
  em sub-rotinas e
    que podem ser
 compartilhadas por
  diferentes scripts.
Vantagens
FácilA maioria dos
 desenvolvedores entende
Bom com Transações
         Bom para definir limites de
           transações. É fácil usar
           ferramentas para tratar
        transações por trás dos panos.
Funciona bem com uma
camada de dados simples
como Row Gateway ou
 Table Data Gateway
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
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. }  
Table Module
  É o meio
termo entre o
   Domain
   Model e
Transaction
   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. 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)
    }  
}  
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)   
    }  

} 
Domain
 Model
É a essência do paradigma OO. Cada objeto
 contém uma parte da lógica, do comportamento
                 relevante a ele.




Objetos
Estrutura a complexidade de forma organizada
DataMapper
Ligação entre
 os objetos do
 domínio e as
  tabelas do
banco de dados
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);  
    }  
}  
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  
    }  
}  
Service
Layer
Divisão
     Uma abordagem comum que divide a
       camada de domínio em duas.
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
Service
 Excelente para inserir
Segurança e Controle de
     Transações.
  Recomendável que
aja como um Façade
 sem comportamento
       próprio.
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
“Minha preferência é por
ter 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