Arquitetura de Software Padroes de Arquitetura de Software - v2 - 1694187129

Arquitetura de Software
Padrões de Arquitetura de Software
CONTEÚDO
Introdução ........................................................................................................................ 3
Arquitetura em Camadas .................................................................................................. 4
Modelo Centralizado (Arquitetura Monolítica) ..................................................................... 4
Modelo Cliente/Servidor ....................................................................................................... 5
Arquitetura de Duas Camadas (Two-tier) .......................................................................... 6
Arquitetura Multicamadas (Multi-tier) .................................................................................. 9
Arquitetura de Três camadas (Three-tier) ........................................................................ 10
Arquitetura em 3/4 Camadas (Web-Based) ........................................................................ 13
Arquitetura Distribuída em ‘N’ Camadas ......................................................................... 14
Arquitetura MVC (Model-View-Controller)...................................................................... 17
MVC vs. Three-tier Architecture ....................................................................................... 20
Domain Driven Design (DDD) .......................................................................................... 21
Linguagem Ubíqua ............................................................................................................... 21
Sistema em Camadas ........................................................................................................... 22
Objetos de Domínio ............................................................................................................. 24
Contexto Delimitados .......................................................................................................... 25
Camada Anticorrupção ........................................................................................................ 25
Arquitetura Hexagonal .................................................................................................... 28
Adaptadores e Portas .......................................................................................................... 30
2
www.resumosdeti.com.br
O conteúdo deste resumo é de uso exclusivo de grupo concurseiros - E-mail: grupoconcurseiros23@gmail.com - ID: 62513 - Data: 8 de
setembro de 2023, vedada, por quaisquer meios e a qualquer título, a sua reprodução, cópia, divulgação e distribuição, sujeitando-se os
infratores à responsabilização civil e criminal.
Introdução
- Arquitetura refere-se a uma representação abstrata de componentes e comportamentos
de um sistema.
- Uma arquitetura bem projetada deve ser capaz de atender aos requisitos funcionais e não
funcionais do sistema e ser suficientemente flexível para suportar requisitos voláteis.
- Uma forma de organizar a arquitetura de um sistema complexo em partes menores é

através de camadas de software:
• Cada camada corresponde a um conjunto de funcionalidades de um sistema de
software.
• Funcionalidades de alto nível dependem de funcionalidades de baixo nível.
- Camadas fornecem um nível de abstração através do agrupamento lógico de subsistemas

relacionados.
3
Arquitetura em Camadas
− Uma forma de organizar a arquitetura é através de camadas de software:
o Cada camada provê um conjunto de funcionalidades em determinado nível de
abstração;
o Tipicamente, uma camada de mais alta abstração depende de uma camada de mais
baixa abstração, e não o contrário;
o Permite que o sistema de software seja mais portável e modificável.
▪ Uma mudança em determinada camada, desde que seja mantida sua
interface, não afeta as outras camadas;
− Vantagens
o Separação de responsabilidades
o Decomposição de complexidade
o Encapsulamento de implementação
o Maior reuso e extensibilidade
− Desvantagens
o Podem penalizar a performance do sistema
o Aumento do esforço e complexidade de desenvolvimento
Modelo Centralizado (Arquitetura Monolítica)

- Programa e dados armazenados em uma única grande máquina – não havia camadas
• Mainframe
- Continham todas as funcionalidades em um único módulo.
- Manutenção difícil.
- A entrada do usuário, verificação, lógica de negócio e acesso a banco de dados estava
presente em um mesmo lugar.
- Acesso através de terminais “burros”.
4
Modelo Cliente/Servidor
- Cliente-servidor é um modelo computacional que separa clientes e servidores, sendo
interligados entre si geralmente utilizando-se uma rede de computadores.
- Cada instância de um cliente pode enviar requisições de dado para algum dos servidores
conectados e esperar pela resposta.
- Por sua vez, algum dos servidores disponíveis pode aceitar tais requisições, processá-las
e retornar o resultado para o cliente.
- O Modelo Cliente/Servidor foi criado tendo como base a descentralização dos dados e
recursos de processamento, em oposição ao Modelo Centralizado.
- Servidor
• Fornecedores de um recurso ou serviço;
• Sempre espera por um pedido de um cliente;
• Atende aos pedidos e, em seguida, responde aos clientes com os dados solicitados;
• Pode se comunicar com outros servidores para atender uma solicitação específica
do cliente;
• Fornece recursos de rede.
- Cliente
• Solicita os serviços oferecidos pelos servidores;
• Inicia pedidos para servidores;
• Espera por respostas;
• Recebe respostas;
• Utiliza recursos da rede.
5
Somerville
− O modelo de arquitetura cliente-servidor é um modelo de sistema distribuído, que mostra
como os dados e o processamento são distribuídos em uma série de processadores, seus
principais componentes são:
o Servidores: oferecem serviços, como por exemplo, servidores de banco de dados.
o Clientes: solicita os serviços oferecidos pelos servidores.
o Rede: permite aos clientes acessarem os servidores.
Arquitetura de Duas Camadas (Two-tier)

- Sistemas cliente-servidor em duas camadas foram dominantes durante
aproximadamente toda a década de 90 e são utilizados até hoje.
- Aplicação rodava na máquina cliente que interagia com um SGBD (servidor de dados).
- Duas abordagens:
• Fat Client/Thin Server
• Thin Client/Fat Server
- Fat Client / Thin Server (Cliente Pesado / Servidor Leve)

• Camada Cliente:
▪ Continha toda a lógica de apresentação
▪ Negócio
▪ Acesso a dados
6
• Camada Servidor:
▪ Remover do servidor o ônus do processamento de dados
▪ Servidor armazena Banco de Dados
- Thin Cliente/Fat Server (Cliente Leve / Servidor Pesado)

• Camada Cliente:
▪ Interface com usuário
• Camada Servidor:
▪ Processamento pesado no servidor
▪ Lógica da aplicação (Regras de negócio)
▪ Banco de dados
7
- Problemas da Arquitetura Cliente-Servidor de Duas Camadas

• Falta de escalabilidade (conexões a bancos de dados)
• Enormes problemas de manutenção (mudanças na lógica de aplicação forçava
instalações)
• Dificuldade de acessar fontes heterogêneas (legado CICS, 3270, …)
FCC
Sobre a arquitetura cliente-servidor em camadas é correto afirmar: Sistemas que usam a
arquitetura cliente-servidor em duas camadas geralmente possuem problemas de falta de
escalabilidade, dificuldade de manutenção e dificuldade de acessar fontes heterogêneas.
No Modelo de 2 Camadas:
• A estação cliente faz acesso direto ao servidor de banco de dados.
• Um conjunto de bibliotecas, localizadas no computador cliente tem a função de
viabilizar a comunicação entre ele e o servidor.
8
Arquitetura Multicamadas (Multi-tier)

- Arquitetura Multicamadas (multi-tier) é uma arquitetura cliente/servidor em que são
separados logicamente:
• Apresentação
• Processamento
• Funções de gerenciamento de dados
- A Arquitetura Multi-tier mais utilizada hoje é a Arquitetura de Três Camadas (three-tier).
- Arquitetura multicamas é uma forma de organização através de camadas de software:

• Cada camada provê um conjunto de funcionalidades em determinado nível de
abstração.
• Tipicamente, uma camada de mais alta abstração depende de uma camada de mais
baixa abstração, e não o contrário.
• Uma mudança em determinada camada, desde que seja mantida sua interface, não
afeta as outras camadas.
- Tier x Layer:
• Tier (física): implica em separação física.
• Layer (lógica): as camadas não precisam rodar em máquinas diferentes.
- Vantagens
• Separação de responsabilidades;
• Decomposição de complexidade;
• Encapsulamento de implementação;
• Maior reuso e extensibilidade.
- Desvantagens
• Podem penalizar a performance do sistema;
• Aumento do esforço e complexidade de desenvolvimento.
FCC
Uma arquitetura em camadas pode ser combinada com uma arquitetura centrada nos
dados em muitas aplicações de bancos de dados.
9
Arquitetura de Três camadas (Three-tier)

- Chamado também de Arquitetura Cliente/Servidor de 3 (três) Camadas.
- Para minimizar o impacto de mudanças nas aplicações, decidiu-se separar a camada de
negócio da camada de interface gráfica, gerando três camadas:
• Camada de Apresentação
• Camada de Aplicação ou Lógica de Negócio
• Camada de Dados, Acesso a Dados ou Armazenamento
- Camada de Apresentação (GUI)

• Contém: Clientes
• Chamados de THIN CLIENT
▪ São enxutos
▪ Desconhecem a lógica da aplicação
• Contém o código para a apresentação da aplicação (entrada e saída de dados)
• A camada de apresentação é altamente depende de ambiente
▪ Páginas WEB (HTML, JavaScript, CSS, JSP, Applet, etc.)
▪ Aplicações Desktop (Windows/Linux Applications, etc.)
▪ Menus baseados em texto (sistemas legados, aplicações móveis, etc.)
- Camada de Aplicação ou Lógica do Negócio (business logic)

• Contém: Servidores de Aplicação
• Coordena a aplicação, processa comandos, toma decisões lógicas, faz avaliações e
implementa as regras de negócio
10
• É inerente ao domínio (negócio) da aplicação

• Vários protocolos podem ser utilizados para ligar esta camada às outras duas
▪ Sockets, HTTP, TCP/IP, etc. (Apresentação)
▪ JDBC, LDAP, ODBC, etc. (Dados)
- Camada de Dados
• Contém: Servidor de Dados
• Contém o código responsável por armazenar e recuperar dados de uma base de
dados ou sistema de arquivos.
• Normalmente há uma subcamada (interface) dentro desta camada que abstrai o
mecanismo de persistência.
▪ O famoso padrão DAO (Data Access Object) é utilizado aqui.
- Vantagens
• É mais fácil de modificar ou substituir qualquer camada sem afetar as outras;
• Separar a lógica de aplicação da lógica de acesso a dados melhora o balanceamento
de carga;
• É mais fácil assegurar políticas de segurança na camada do servidor sem interferir
nos clientes.
- Desvantagens
• Quanto mais camadas houver na arquitetura, maior é a tendência de a
performance diminuir;
• O rastreamento de ponta-a-ponta em sistemas complexos com muitas camadas é
uma tarefa complicada
• Requer um maior esforço de desenvolvimento.
FCC
A arquitetura multicamadas divide-se em três camadas lógicas. São elas: Apresentação,
Negócio e Acesso a Dados.
Em relação ao modelo da arquitetura Cliente/Servidor de três camadas, considere:
• A camada do cliente não tem que se preocupar com os processos,
responsabilizando-se apenas pelas solicitações de serviço à camada
intermediária.
• A camada intermediária é responsável pelo processamento da aplicação em si,
ou seja, recebe solicitações dos clientes, processa os dados e envia-os para
armazenamento no servidor de conteúdo.
11
• Na camada intermediária, um monitor de transações adquire características de

gerenciar processos, transações e a comunicação entre o cliente e o servidor.
• O objetivo do servidor de aplicação é compartilhar a lógica de negócios e os
mecanismos de recuperação de dados.
Um sistema cliente servidor de três camadas oferece uma clara separação entre a lógica
da aplicação e a interface com o usuário e os dados.
Uma das vantagens da arquitetura de três camadas é permitir que qualquer uma das três
camadas sejam atualizadas ou substituídas de forma independente em resposta a
mudanças nos requisitos ou na tecnologia utilizada.
No modelo de três camadas, toda a Lógica do negócio fica no servidor de aplicações. O
Cliente não tem acesso direto ao banco de dados, sem antes passar pelo servidor de
aplicações, onde estão contidas as regras do negócio, que determinam de que maneira os
dados serão utilizados. A camada Apresentação reside no programa instalado no cliente.
No Modelo de 3 camadas:
• As conexões no banco de dados são realizadas pelo servidor de aplicação.
• O gargalo de I/O (Input/Output) é evitado, uma vez que é possível ter a mesma regra
de negócio dividida entre vários servidores através do balanceamento de carga.
CESPE
Em arquitetura multicamadas, o servidor de aplicação nada mais é do que um programa
que fica entre o aplicativo cliente e o sistema de gerenciamento de banco de dados.
Normalmente, a arquitetura em três camadas conta com as camadas de apresentação, de
aplicação e de dados.
A arquitetura cliente/servidor tradicional vem sendo substituída pela de múltiplas
camadas. Conceitualmente, uma aplicação pode ter qualquer número de camadas. A
arquitetura denominada three-tier, por exemplo, define três camadas lógicas: camada de
interface de usuário, camada de regra de negócios e camada de acesso a banco de dados.
12
Arquitetura em 3/4 Camadas (Web-Based)

- A arquitetura em 3 camadas original sofre problemas:
• A instalação inicial dos programas no Desktop é cara;
• O problema de manutenção ainda persiste quando há mudanças à camada de
apresentação;
• Não se pode instalar software facilmente num desktop que não está sob seu
controle administrativo.
- Então, usa-se o Browser como Cliente Universal.

• Conceito de Intranet;
• A camada de aplicação se quebra em duas: Web e Aplicação;
• Evitamos instalar qualquer software no desktop e, portanto, problema de
manutenção;
• Evitar instalação em computadores de cliente, parceiros, fornecedores, etc.
- Às vezes continua-se a chamar isso de 3 camadas, porque as camadas Web e Aplicação

frequentemente rodam na mesma máquina (para pequenos volumes).
CESPE
Uma das principais arquiteturas para o desenvolvimento de sistemas de informação
distribuídos consiste na arquitetura cliente-servidor em três camadas, sendo uma camada
de banco de dados, normalmente implementada em um SGBD, uma camada de negócios
consistindo de um servidor principal (Web) associado a outros servidores de aplicação e a
camada de interface com o usuário, composta por um cliente compatível com o servidor
13
da camada de negócios (Web browser). Essa arquitetura tem recebido um forte apelo, com
a utilização de tecnologia Web nas camadas de negócio e de usuário, o que confere alta
portabilidade aos sistemas.
Em uma aplicação de acesso a banco de dados segundo a arquitetura em três camadas
via web, a interação entre os clientes (camada de apresentação) e o banco de dados
(camada de armazenamento) é intermediada por uma camada de servidor de aplicação
que fisicamente pode se localizar na plataforma computacional em que está o banco de
dados.
CESGRANRIO
A arquitetura de 3 camadas é comumente utilizada no desenvolvimento de aplicações para
Internet. Nesse tipo de arquitetura, a lógica da aplicação é dividida entre as camadas físicas
cliente, servidor de aplicação e banco de dados. São características deste tipo de
arquitetura o(a):
- Aumento da disponibilidade do serviço oferecido através da possibilidade de
redundância dos servidores de aplicação e banco de dados.
- Facilidade de integração de múltiplas fontes de dados.
- Maior segurança, uma vez que o banco de dados não é acessado diretamente pelo
cliente.
- Aplicação em larga escala, possibilitando o atendimento a vários clientes
simultaneamente.
Arquitetura Distribuída em ‘N’ Camadas

- Os problemas remanescentes:
• Não há suporte a Thin Clients (PDA, celulares, smart cards, ...) pois preciso usar um
browser (pesado) no cliente;
• Dificuldade de criar software reutilizável;
• Fazer aplicações distribuídas multicamadas é difícil.
- As camadas podem ter vários nomes:

1. Camadas de Apresentação, Interface, Cliente;
2. Camada Web;
3. Camada de Aplicação, Negócios (Business);
4. Camada de Dados, Enterprise Information System (EIS).
14
FCC
Retirar a camada Apresentação do cliente e centralizá-la, na maioria das vezes, em um
servidor Web, é a ideia básica do modelo de quatro camadas. Com isso, o Cliente passa a
ser o navegador (browser) utilizado pelo usuário. Todo o acesso do Cliente ao banco de
dados é feito de acordo com as regras contidas no servidor de aplicações, onde estão
contidas as regras do negócio, que determinam de que maneira os dados serão utilizados.
A camada Apresentação passa a residir no servidor WEB.
São aspectos que podem caracterizar uma arquitetura cliente-servidor, estabelecida
logicamente em 4 camadas:
• A camada Cliente contém um navegador de Internet, caracterizado como cliente
universal.
• A camada de Lógica do Negócio se quebra em duas: camada de Aplicação e
camada Web, em que o servidor Web representa a camada de Apresentação.
• Na camada de Lógica do Negócio, o servidor de aplicação passa a
utilizar middleware, para suporte a thin clients (PDA, celulares, smart cards, etc) e
soluções baseadas em componentes, tais como, J2EE e .Net.
• Se, de um lado, a camada de Aplicação estabelece uma interface com a camada de
Dados, do outro o faz com a camada Web e com os thin clients da camada Cliente.
15
CESPE
Na arquitetura multicamadas, as camadas podem ter vários nomes. Por exemplo, a
camada de aplicação pode ser chamada de camada de negócio, e a camada de dados pode
receber o nome de camada EIS (enterprise information system).
16
Arquitetura MVC (Model-View-Controller)

− Principal padrão de arquitetura em três camadas utilizado no Mercado.
− Model – View – Controller (MVC) é um padrão de arquitetura de software que propõe a
divisão do software em três camadas distintas que se comunicam entre si.
o Esse padrão favorece o baixo acoplamento, melhorando a estrutura do software.
17
- Camada de Visão (View)

• É a camada de interface com o usuário.
• Responsável por receber a entrada de dados e apresentar os resultados.
• Não está preocupada em como ou onde a informação foi obtida, apenas exibe a
informação.
• Inclui elementos de exibição no cliente.
▪ HTML, XML, ASP, Applets, etc.
• Pode requerer dados diretamente da camada de Modelo.
- Camada de Controle (Controller)

• Responsável por controlar e mapear as ações do usuário, fazendo o papel de
intermediário entre a camada de Visão e de Modelo;
• Atualiza o Modelo;
• Seleciona a Visão.
- Camada de Modelo (Model)

• Responsável por modelar os dados e o comportamento por trás das regras de
negócio;
• Se preocupa com o armazenamento, manipulação e geração dos dados;
• Objetos do Modelo são normalmente reusáveis, distribuídos, persistentes e
portáveis para várias plataformas.
FCC
No padrão MVC é possível definir grupos de componentes principais: o Model (Modelo),
o View (Apresentação) e o Controller (Controle). Deve fazer parte do componente Model,
as classes com métodos conhecidos como setters e getters e que representam tabelas do
banco de dados.
O padrão de arquitetura MVC é um modelo de camadas que divide a aplicação em três
componentes: Model (modelo), View (visualizador) e Controller (controlador). As funções
de cada um destes três componentes são apresentadas abaixo:
- View: exibe para o usuário os dados fornecidos pelo controle e estabelece uma
interface para interação entre o usuário e a aplicação.
- Controller: interpreta eventos de entrada e envia requisições para o modelo de
dados; em seguida, processa os dados carregados a partir do modelo e envia para o
visualizador.
- Model: encapsula o acesso aos dados e funções básicas da aplicação, fornecendo ao
usuário procedimentos que executam tarefas específicas.
18
MVC é o padrão de projeto utilizado em aplicações WEB que permite separar as páginas e
classes da aplicação em três grupos (muitas vezes chamados de camadas) conhecidos
como Apresentação, Controle e Modelo.
O componente Controller do MVC define o comportamento da aplicação, as ações do
usuário para atualizar os componentes de dados e seleciona os componentes para exibir
respostas de requisições.
No projeto de arquitetura modelo-visão-controle (MVC), o controlador processa e
responde a eventos e invoca alterações ao modelo, o modelo encapsula funcionalidades e
objetos de conteúdo e a visão renderiza a interface de usuário a partir do modelo.
Control: Seleção do comportamento do modelo.
Model: Encapsulamento dos objetos de conteúdo.
View: Requisição das atualizações do modelo.
Em uma Aplicação Web desenvolvida utilizando o design pattern MVC, as páginas HTML e
as classes com métodos que acessam o banco de dados e executam instruções SQL são
representadas, respectivamente, nos componentes View e Model.
Com relação à arquitetura MVC, considere:
• O MODEL representa os dados da empresa e as regras de negócio que governam o
acesso e atualização destes dados.
• O VIEW acessa os dados da empresa através do MODEL e especifica como esses
dados devem ser apresentados. É de responsabilidade do VIEW manter a
consistência em sua apresentação, quando o MODEL é alterado.
• O CONTROLLER traduz as interações do VIEW em ações a serem executadas pelo
MODEL. Com base na interação do usuário e no resultado das ações do MODEL, o
CONTROLLER responde selecionando uma VIEW adequada.
A camada Controller geralmente possui um componente controlador padrão criado para
atender a todas as requisições do cliente.
CESPE
No MVC (model-view-controller), um padrão recomendado para aplicações interativas,
uma aplicação é organizada em três módulos separados. Um para o modelo de aplicação
com a representação de dados e lógica do negócio, o segundo com visões que fornecem
apresentação dos dados e input do usuário e o terceiro para um controlador que despacha
pedidos e controle de fluxo.
O MVC promove a estrita separação de responsabilidades entre os componentes de uma
interface.
O controlador é responsável pela coordenação entre atualizações no modelo e interações
com o usuário.
19
No padrão de desenvolvimento modelo-visualização-controlador (MVC), o controlador é

o elemento responsável pela interpretação dos dados de entrada e pela manipulação do
modelo, de acordo com esses dados.
Aplicações web que não requerem controle de segurança podem ser construídas
utilizando-se a arquitetura conhecida como modelo 1 ou MVC (Model View Controller).
Por meio do MVC, é possível o desenvolvimento de aplicações em 3 camadas para a Web.
MVC vs. Three-tier Architecture

- Arquitetura em Três Camadas “pura” é LINEAR → toda a comunicação deve passar pela
Camada Intermediária.
- Arquitetura MVC é TRIANGULAR → nem toda a comunicação passa pelo Controlador.

• A Visão despacha atualizações para o Controlador
• O controlador atualiza o modelo
• A Visão é atualizada diretamente pelo Modelo
FCC
Na arquitetura de três camadas (three-tier) a comunicação não é linear, mas sim triangular,
ou seja, os componentes de apresentação podem se comunicar diretamente com os
componentes de dados sem passar pela camada intermediária. ERRADO
Comentário:
A Banca inverteu as definições. A Arquitetura MVC que é triangular.
A arquitetura de três camadas (three-tier) é outra forma de se referir ao
design pattern MVC. Three-tier e MVC são a mesma coisa, pois separam os componentes
da aplicação em três camadas com a mesma topologia. ERRADO
Comentário:
Apesar de possuírem 3 entidades, são padrões distintos.
20
Domain Driven Design (DDD)

− DDD é uma abordagem para desenvolvimento de sistemas de software complexos, em
que:
o O foco está no domínio do sistema;
o Desenvolvedores e especialistas no negócio devem explorar esse domínio de forma
colaborativa;
o Como resultado, eles devem se comunicar usando uma linguagem ubíqua, mas
dentro de um contexto delimitado.
− A linguagem ubíqua do sistema deve ser usada também no seu código, para nomear
variáveis, parâmetros, métodos, classes, pacotes, etc.
o Especificamente, um projeto DDD deve fazer uso dos seguintes tipos de objetos
principais: entidades, objetos de valor, serviços, agregados e repositórios.
− Também é importante mencionar que o DDD é um padrão de modelagem de software

orientado a objetos que procura reforçar conceitos e boas práticas relacionadas à OO.
Essencialmente as relacionadas abaixo:
o Alinhamento do código com o negócio;
o Favorecer reutilização;
o Mínimo de acoplamento;
o Independência da Tecnologia.
Linguagem Ubíqua
− Linguagem Ubíqua (ou Linguagem Onipresente) é um conceito central de DDD.
o Ela consiste de um conjunto de termos que devem ser plenamente entendidos
tanto por especialistas no domínio (usuários do sistema) como por
desenvolvedores (implementadores do sistema).
o Ou seja, para um projeto de software dar certo, DDD defende que esses dois papéis
– especialistas no domínio e desenvolvedores – devem falar a mesma língua, que
vai constituir a chamada Linguagem Ubíqua do sistema.
− Essa ideia é ilustrada na seguinte figura:
21
− A figura deixa claro que existem termos que só os especialistas de domínio conhecem.
o Já outros termos, de cunho tecnológico, são do conhecimento apenas dos
desenvolvedores.
o Porém, existe um conjunto de termos que devem ser do conhecimento de ambos,
os quais formam a Linguagem Ubíqua do sistema.
− Os termos da Linguagem Ubíqua são usados com dois propósitos:

o Para possibilitar uma comunicação fluida entre desenvolvedores e especialistas no
domínio.
o Para nomear entidades do código do sistema, como classes, métodos, atributos,
pacotes, módulos, tabelas de bancos de dados, rotas de APIs, etc.
Sistema em Camadas
− Interface de Usuário
o Parte responsável pela exibição de informações do sistema ao usuário e também
por interpretar comandos do usuário;
− Aplicação
o Essa camada não possui lógica de negócio.
o Ela é apenas uma camada fina, responsável por conectar a Interface de Usuário às
camadas inferiores;
22
− Domínio
o Representa os conceitos, regras e lógicas de negócio.
o Todo o foco de DDD está nessa camada.
− Infraestrutura
o Fornece recursos técnicos que darão suporte às camadas superiores.
o São normalmente as partes de um sistema responsáveis por persistência de dados,
conexões com bancos de dados, envio de mensagens por redes, gravação e leitura
de discos, etc.
23
Objetos de Domínio
− Depois de dividirmos o sistema em camadas, nos preocuparemos apenas com a camada
de domínio.
− Para modelar essa parte, utilizamos alguns Padrões propostos em DDD.

o Esses padrões são chamados de blocos de construção e serão utilizados para
representar nosso modelo abstrato.
− Esses blocos podem ser:

o Entidades
▪ Uma entidade é um objeto que possui uma identidade única, que o
distingue dos demais objetos da mesma classe.
▪ Por exemplo, cada Usuário da nossa biblioteca é uma entidade, cujo
identificador é o seu número de matrícula na universidade.
o Objetos de Valor
▪ Por outro lado, objetos de valor (value objects) não possuem um
identificador único.
▪ Assim, eles são caracterizados apenas por seu estado, isto é, pelos valores
de seus atributos.
▪ Por exemplo, o Endereço de um Usuário da biblioteca é um objeto de valor.
• Veja que se dois Endereços tiverem exatamente os mesmos valores
para rua, número, cidade, CEP, etc, eles serão idênticos.
o Serviços
▪ Existem operações importantes do domínio que não se encaixam em
entidades e objetos de valor.
▪ Assim, o ideal é criar objetos específicos para implementar essas operações.
• No jargão de DDD, esses objetos são chamados de serviços.
• Em alguns sistemas, é comum ver esses objetos sendo chamados
também de gerenciadores ou controladores.
▪ Objetos de serviço não devem possuir estado, isto é, eles devem ser
stateless.
• Por isso, eles não costumam ter atributos, mas apenas métodos.
▪ Serviços normalmente são implementados como singletons, ou seja,
possuem uma única instância durante a execução do sistema.
o Agregações
24
▪ Agregados (aggregates) são coleções de entidades e objetos de valor.

• Ou seja, algumas vezes não faz sentido raciocinar sobre entidades e
objetos de valor de forma individual.
▪ Em vez disso, temos que pensar em grupos de objetos para ter uma visão
consistente com o domínio que estamos modelando.
o Repositórios
▪ Um repositório é então um objeto usado para recuperar outros objetos de
domínio de um banco de dados.
▪ Seu objetivo é prover uma abstração que blinde os desenvolvedores de
preocupações relacionadas com acesso a bancos de dados.
▪ Normalmente, repositórios são criados para recuperar entidades ou
agregados.
Contexto Delimitados
− Com o tempo, sistemas de software ficam mais complexos e abrangentes.
o Por isso, é irrealista imaginar que sistemas de organizações grandes e complexas
vão possuir um modelo de domínio único e baseado na mesma linguagem ubíqua.
− Em vez disso, é natural que tais organizações tenham sistemas que atendem a usuários
com perfis e necessidades diferentes, o que complica a definição de uma linguagem
ubíqua.
o A solução para esse problema consiste em quebrar tais domínios complexos em
domínios menores, os quais em DDD são chamados de Contextos Delimitados
(Bounded Contexts).
Camada Anticorrupção
− Às vezes, temos que integrar sistemas que estão em contextos delimitados diferentes.
o Por exemplo, um sistema A precisa usar serviços de um sistema B, que pode
inclusive ser um sistema externo, isto é, de uma outra organização.
o Para evitar que A tenha que se adaptar e usar, mesmo que parcialmente, a
linguagem ubíqua de B, pode-se usar uma Camada Anticorrupção para mediar essa
comunicação.
− Essa camada é formada por três tipos principais de classes:

o Classes de Serviço, cujos métodos serão chamados por A e que, portanto, seguem
a linguagem ubíqua desse sistema.
25
o Classes Adaptadoras, que convertem o modelo e os tipos de dados de B para o

modelo e tipos de dados de A.
▪ Ou seja, essas classes vão isolar elementos próprios de B e evitar que eles
cheguem até o sistema A.
o Uma Classe de Fachada, usada para acessar o sistema B.

▪ O papel dessa classe é facilitar o uso de B, principalmente quando ele é um
sistema legado com uma interface complexa e antiga.
CESPE
O DDD (domain-driven design) não tem como foco principal a tecnologia, mas o
entendimento das regras de negócio e de como elas devem estar refletidas no código e no
modelo de domínio.
O uso de DDD será aplicável quando o software atender uma área de negócio muito
específica e complexa.
O domain-driven design é parte das práticas do princípio lean da engenharia ágil voltada a
arquiteturas que devem ser conduzidas por requisitos técnicos subjacentes do sistema, e
não por planejamento especulativo para um futuro que pode mudar.
De acordo com os padrões de DDD (domain-driven design), ao se escrever um novo sistema
para também interagir com um sistema legado (considerado um código de difícil
manutenção), cria-se uma camada entre os dois sistemas denominada camada
anticorrupção.
Um dos princípios-chave do Domain-Driven Design é o uso de uma linguagem ubíqua com
termos bem definidos, que integram o domínio do negócio e que são utilizados entre
desenvolvedores especialistas de negócio.
O bounded contexto é um limite conceitual do modelo, sendo considerado um delimitador
de domínio.
No desenvolvimento embasado em domain-driven design, a definição da tecnologia a ser
utilizada tem importância secundária no projeto.
No Domain-Driven Design, a Ubiquitous Language é considerada uma linguagem do
projeto de desenvolvimento de software utilizada para comunicação de todos os
envolvidos no projeto.
OUTRAS BANCAS
Eric Evans, criador do DDD (Domain-Driven Design), afirma que, no DDD, foca-se numa
linguagem que possa descrever sucintamente qualquer situação no domínio e descrever
o que faremos para resolver ou que tipos de cálculos precisamos realizar. Essa linguagem
26
pode ser compartilhada entre pessoas do negócio, especialistas de domínio, assim como
os programadores que irão escrever o software, e isso chamamos de linguagem ubíqua.
Domain Driven Design (DDD) é uma abordagem de projeto de software disciplinada que
reúne um conjunto de conceitos, técnicas e princípios para construção de softwares
baseados em modelo de domínio.
Um dos objetivos do Domain Driven Design é aproximar o desenvolvimento de software
do domínio do problema.
O Domain-Driven Design – DDD utiliza o conceito de divisão do sistema em camadas. As
camadas desse modelo são: interface com usuário, aplicação, domínio e infraestrutura.
27
Arquitetura Hexagonal
− A ideia da Arquitetura Hexagonal é construir sistemas que favorecem reusabilidade de
código, alta coesão, baixo acoplamento, independência de tecnologia e que são mais
fáceis de serem testados.
− Uma Arquitetura Hexagonal divide as classes de um sistema em dois grupos principais:

o Classes de domínio, isto é, diretamente relacionadas com o negócio do sistema.
o Classes relacionadas com infraestrutura, tecnologias e responsáveis pela
integração com sistemas externos (tais como bancos de dados).
− Além disso, em uma Arquitetura Hexagonal, classes de domínio não devem depender de
classes relacionadas com infraestrutura, tecnologias ou sistemas externos.
o A vantagem dessa divisão é desacoplar esses dois tipos de classes.
− Assim, as classes de domínio não conhecem as tecnologias – bancos de dados, interfaces

com usuário e quaisquer outras bibliotecas – usadas pelo sistema.
o Consequentemente, mudanças de tecnologia podem ser feitas sem impactar as
classes de domínio.
o Talvez ainda mais importante, as classes de domínio podem ser compartilhadas por
mais de uma tecnologia.
▪ Por exemplo, um sistema pode ter diversas interfaces (Web, mobile, etc).
− Em uma arquitetura hexagonal, a comunicação entre as classes dos dois grupos é mediada
por adaptadores, isto é, por classes que implementam o padrão de projeto de mesmo
nome (Adapter).
− Visualmente, a arquitetura é representada por meio de dois hexágonos concêntricos (veja

figura).
o No hexágono interno, ficam as classes do domínio (ou classes de negócio, se você
preferir).
o No hexágono externo, ficam os adaptadores.
o Por fim, as classes de interface com o usuário, classes de tecnologia ou de sistemas
externos ficam fora desses dois hexágonos.
28
− Cada face do hexágono representa um motivo pelo qual o sistema deve se comunicar com
o mundo exterior.
o É por isso que são hexágonos concêntricos e não círculos concêntricos.
− Dentre os motivos que requerem comunicação com o mundo exterior podemos citar os
seguintes: interagir com seus usuários (por meio de algum tipo de interface, seja ela
gráfica, Web, mobile, terminal, etc), persistir informações, enviar informações para outros
sistemas, etc.
29
Adaptadores e Portas
− Em uma Arquitetura Hexagonal, o termo porta designa as interfaces usadas para
comunicação com as classes de domínio (veja que interface aqui significa interface de
programação; por exemplo, uma interface de Java).
− Existem dois tipos de portas:

o Portas de entrada:
▪ São interfaces usadas para comunicação de fora para dentro, isto é, quando
uma classe externa precisa chamar um método de uma classe de domínio.
o Portas de saída:
▪ São interfaces usadas para comunicação de dentro para fora, isto é, quando
uma classe de domínio precisa chamar um método de uma classe externa.
− O importante é que as portas são independentes de tecnologia.

o Portanto, elas estão localizadas no hexágono interior.
− Por outro lado, os sistemas externos, normalmente, usam alguma tecnologia, seja ela de
comunicação (REST, gRPC, GraphQL, etc), de bancos de dados (SQL, noSQL, etc), de
interação com o usuário (Web, mobile, etc), etc.
− Daí a necessidade de componentes localizados no hexágono mais externo da arquitetura

– os adaptadores –, os quais atuam de um dos dois modos a seguir:
o Eles recebem chamadas de métodos vindas de fora do sistema e encaminham
essas chamadas para métodos adequados das portas de entrada.
o Eles recebem chamadas vindas de dentro do sistema, isto é, das classes de
domínio, e as direcionam para um sistema externo, tais como um banco de dados,
um outro sistema da organização ou mesmo de terceiros.
− Exemplo: Sistema de Bibliotecas

o A próxima figura mostra a arquitetura hexagonal de um sistema para
gerenciamento de bibliotecas:
30
− Na figura, podemos observar que os usuários acessam o sistema por meio de três
interfaces: Web, mobile e por meio de um sistema externo.
− Qualquer que seja a forma de acesso, ele é sempre mediado por adaptadores.
− Em seguida, esses adaptadores comunicam-se com uma porta de entrada, que define
métodos para pesquisa no catálogo da biblioteca, para realização de empréstimos, para
cadastro de usuários, etc.
o Concretamente, esses métodos são implementados pelas classes de domínio.
o No sistema em questão, podem existir classes do tipo Livro, Usuario, Bibliotecario,
Emprestimo, Reserva, etc.
− O sistema precisa também persistir algumas informações.

o Para isso, ele usa uma porta de saída, com métodos para salvar e ler dados de
livros, salvar e ler dados de empréstimos, etc.
31
o Plugado nessa porta temos um adaptador, que realiza as operações em um banco

de dados relacional.
− Assim, um sistema pode possuir várias portas de entrada e de saída (sempre localizadas
no hexágono interior, junto às classes de domínio).
o Em uma determinada porta, seja ela de entrada ou de saída, podemos plugar um
ou mais adaptadores, os quais ficam sempre localizados no hexágono mais
externo.
CESPE/CEBRASPE
Em uma arquitetura hexagonal, as classes de domínio independem das classes de
infraestrutura, tecnologias e sistemas externos.
32

Arquitetura de Software Padroes de Arquitetura de Software - v2 - 1694187129

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquitetura de Software Padroes de Arquitetura de Software - v2 - 1694187129

Enviado por

Direitos autorais:

Formatos disponíveis

Arquitetura de Software

Padrões de Arquitetura de Software

- Uma forma de organizar a arquitetura de um sistema complexo em partes menores é

- Camadas fornecem um nível de abstração através do agrupamento lógico de subsistemas

Modelo Centralizado (Arquitetura Monolítica)

Arquitetura de Duas Camadas (Two-tier)

- Fat Client / Thin Server (Cliente Pesado / Servidor Leve)

- Thin Cliente/Fat Server (Cliente Leve / Servidor Pesado)

- Problemas da Arquitetura Cliente-Servidor de Duas Camadas

Arquitetura Multicamadas (Multi-tier)

- A Arquitetura Multi-tier mais utilizada hoje é a Arquitetura de Três Camadas (three-tier).

- Arquitetura multicamas é uma forma de organização através de camadas de software:

Arquitetura de Três camadas (Three-tier)

- Camada de Apresentação (GUI)

- Camada de Aplicação ou Lógica do Negócio (business logic)

• É inerente ao domínio (negócio) da aplicação

• Na camada intermediária, um monitor de transações adquire características de

Arquitetura em 3/4 Camadas (Web-Based)

- Então, usa-se o Browser como Cliente Universal.

- Às vezes continua-se a chamar isso de 3 camadas, porque as camadas Web e Aplicação

Arquitetura Distribuída em ‘N’ Camadas

- As camadas podem ter vários nomes:

Arquitetura MVC (Model-View-Controller)

- Camada de Visão (View)

- Camada de Controle (Controller)

- Camada de Modelo (Model)

No padrão de desenvolvimento modelo-visualização-controlador (MVC), o controlador é

MVC vs. Three-tier Architecture

- Arquitetura MVC é TRIANGULAR → nem toda a comunicação passa pelo Controlador.

Domain Driven Design (DDD)

− Também é importante mencionar que o DDD é um padrão de modelagem de software

− Essa ideia é ilustrada na seguinte figura:

− Os termos da Linguagem Ubíqua são usados com dois propósitos:

− Para modelar essa parte, utilizamos alguns Padrões propostos em DDD.

− Esses blocos podem ser:

▪ Agregados (aggregates) são coleções de entidades e objetos de valor.

− Essa camada é formada por três tipos principais de classes:

o Classes Adaptadoras, que convertem o modelo e os tipos de dados de B para o

o Uma Classe de Fachada, usada para acessar o sistema B.

− Uma Arquitetura Hexagonal divide as classes de um sistema em dois grupos principais:

− Assim, as classes de domínio não conhecem as tecnologias – bancos de dados, interfaces

− Visualmente, a arquitetura é representada por meio de dois hexágonos concêntricos (veja

− Existem dois tipos de portas:

− O importante é que as portas são independentes de tecnologia.

− Daí a necessidade de componentes localizados no hexágono mais externo da arquitetura

− Exemplo: Sistema de Bibliotecas

− O sistema precisa também persistir algumas informações.

o Plugado nessa porta temos um adaptador, que realiza as operações em um banco

Você também pode gostar