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/