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/