Arquitetura e padrões de software

Apresentação em tema: "Arquitetura e padrões de software"— Transcrição da apresentação:

1 Arquitetura e padrões de software
Eduardo Bezerra (CEFET/RJ)

2 Créditos Apresentação baseada nos livros a seguir.
Martin Fowler, Padrões de Arquitetura de Aplicações Corporativas, Porto Alegre: Bookman, 2006. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003.

3 Camadas típicas de uma Aplicação Corporativa

4 Sumário Camadas típicas de uma AC Organização das camadas de uma AC

5 Camadas típicas de uma AC

6 Camadas típicas de uma AC
Não há um consenso na terminologia usada para fazer referência às camadas componentes de uma aplicação corporativa. Duas taxonomias normalmente aceitas são as propostas por Martin Fowler e Eric Evans: Fowler: Apresentação, Serviços, Negócio, Acesso a dados. Evans: IU, Aplicação, Domínio, Infraestrutura.

7 Camadas da arquitetura de uma AC
Fonte: DDD Quickly (

8 Camada da interface com o usuário
Responsável pela interação com o usuário. Outro nome: camada da apresentação. Obtém e apresenta informações ao usuário. Tem o papel de apresentar as informações geradas pelo sistema em um formado adequado. O “usuário” aqui não necessariamente é um ser humano.

9 Camada da interface com o usuário
Para uma mesma aplicação, pode haver diversas “perspectivas” dessa camada. Fonte da figura:

10 Camada da aplicação (ou serviço)
Camada de serviço Demais camadas Interface via linha de comando Interface WEB (navegador) app (dispositivo móvel)

11 Camada da aplicação (ou serviço)
Esta camada consiste de fachadas que coordenam as atividades da aplicação ao delegar tarefas (requisitadas na camada da apresentação) para a camada de domínio.

12 Camada da aplicação (ou serviço)

13 Camada do domínio (ou negócio)
Esta é a camada principal de um sistema de software, pois representa os conceitos do negócio (comportamento e estado). O estado dos objetos e sua validação são localizados nessa camada. Para fins de reusabilidade, o ideal é que esta camada dependa o mínimo possível de aspectos técnicos (JSP/JSF, Struts, JAXB, Hibernate, EJB, etc.). Infrastructure code can be best isolated from a rich domain model using AOP and DI.

14 Camada do domínio (ou negócio)

15 Camada do domínio (ou negócio)
A camada de domínio de uma aplicação adiciona valor à camada de persistência. A camada de persistência provê serviços de persistência de dados da aplicação; A camada de domínio persiste dados e também provê serviços para aplicar regras do negócio a esses dados.

16 Camada da infra-estrutura
Os aspectos técnicos da aplicação são posicionados (implementados) nesta camada. persistência, distribuição, auditoria (logging), autenticação/autorização, etc.

17 Organização das camadas de uma AC

18 Organização da camada da IU
Deve ser mantida tão fina quanto possível. Para tal, independente da linguagem, é recomendado que se utilize o padrão arquitetural MVC na organização dessa camada.

19 Organização da camada da IU
O uso do MVC resulta na separação entre a lógica da IU e a lógica da aplicação. Melhora a coesão da arquitetura. Abre caminho para a publicação de serviços da aplicação por meio de WEB services. Facilita a criação de testes automatizados. De acordo com o princípio da separação de responsabilidades.

20 Organização da camada da aplicação
O propósito dessa camada é conter classes que são contêineres das operações de sistema. Essa camada não apresenta complicações técnicas sérias. pois serve como um tradutor de chamadas às funções da camada de domínio.

21 Organização da camada da aplicação
Na organização dessa camada, é possível criar uma classe por caso de uso. Camada da apresentação Camada da aplicação

22 Organização da camada do domínio
A questão fundamental aqui é decidir se essa camada deve ou não ser isolada para facilitar a criação de testes automatizados. potencializar o reuso de código. A utilização de um framework de persistência também facilita (ou diminui a dificuldade) na manipulação dos objetos. Fator negativo: curva de aprendizado é acentuada.

23 Organização da camada do domínio
O adequado é que a validações das regras do negócio estejam sempre nesta camada. Um aluno não pode se inscrever em uma disciplina para a qual não possua os pré-requisitos necessários. Em um semestre letivo, um aluno não pode se inscrever em uma quantidade de disciplinas cuja soma de créditos ultrapasse 20

24 Organização da camada do domínio
A aplicação do princípio do encapsulamento é fundamental nesta camada. Compare essas duas abordagens

25 Organização da camada do domínio
A correta aplicação do princípio do encapsulamento resulta em um projeto OO em que cada classe possui comportamento para que cada um de seus objetos se mantenha consistente. Como exemplo de inconsistência, considere um objeto Professor que possua uma matrícula de comprimento diferente do especificado. Inconsistências em objetos de uma classe surgem porque o encapsulamento foi violado no projeto.

26 Layers pattern [...], partition a complex program into LAYERS. Develop a design within each LAYER that is cohesive and that depends only on the layers below. Follow standard architectural patterns to provide loose coupling to the layers above. Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code. The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model. This allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work. Fonte: DDD Quickly

27 Organização da camada de infra
Essa é a camada mais complicada do ponto de vista técnico. No desenvolvimento de software corporativo, é comum a utilização de frameworks de aplicação e de bibliotecas de software (APIs) na implementação desta camada.

28 Organização da camada de infra
Exemplos de aspectos importantes nessa camada e de frameworks/APIs relacionados: Persistência dos objetos  JPA, Hibernate IU  Spring MVC, JSF, Java Swing. Autenticação e autorização  Spring Security. Distribuição de objetos  Java RMI Auditoria (logging)  log4j Injeção de dependências  Spring, Google Guice