1.
Arquitetura de SoftwarePerformance, Layers e Domain LayerAndré Faria Gomes@andrefaria

2.
Conceitos dePerformance

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 nula500 Ms

6.
ThroughputQuanto pode ser feitoem um dado intervalo de tempo1588 bytes/segundo900 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 recursosUm sistema que realiza 50 transações em 1CPU é melhor do que que faz 80 com 2.

10.
Escalabilidade O quanto adicionar recursos(hardware) afeta a performance?

11.
Horizontal Melhorar recursos da máquinaVertical Aumentar o número de servidores

12.
PadrõesSão propostas desoluçõ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 umcamada sem afetar as outras

16.
SubstituiçãoSubstituir 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.
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.
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 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.
Um procedimento único para cada açãodo 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 umacamada de dados simplescomo Row Gateway ou Table Data Gateway

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.
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 meiotermo entre o Domain Model eTransaction 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.
DataMapperLigação entre os objetos do domínio e as tabelas dobanco 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.
ServiceLayer

44.
Divisão Uma abordagem comum que divide a camada de domínio em duas.

45.
API A camada deapresentação interagecom o domínio apenas através do ServiceLayer que atua como uma API da aplicação

46.
Service Excelente para inserirSegurança e Controle de Transações. Recomendável queaja como um Façade sem comportamento próprio.

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.
“Minha preferência é porter 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/