AT

Engenharia da Computação
Melhores Práticas de Codificação

Matias Reinke

Correntina BA
23 de Junho de 2024
1. Qual é o papel dos Design Patterns na solução
de problemas de software?
Design Patterns, ou Padrões de Projeto, desempenham um papel crucial na
resolução de problemas de software ao fornecer soluções reutilizáveis e
comprovadas para dilemas comuns que surgem durante o desenvolvimento de
sistemas. Eles são como guias que auxiliam os desenvolvedores a evitar
"reinventar a roda" e a seguir práticas de codificação que são bem aceitas e
testadas pela comunidade de desenvolvimento.

Esses padrões promovem a reutilização de código, facilitam a manutenção e a

escalabilidade dos sistemas, e aprimoram a comunicação entre os
desenvolvedores ao fornecer uma linguagem comum. Ao adotar Design
Patterns, os desenvolvedores podem garantir que o código seja mais robusto,
flexível e compreensível.

Por exemplo, o padrão Singleton é amplamente utilizado para assegurar que

uma classe tenha apenas uma única instância e forneça um ponto de acesso
global a essa instância. Isso é particularmente útil em situações como
gerenciadores de conexão com banco de dados, onde uma única instância
pode ser compartilhada por todo o aplicativo, garantindo consistência e
eficiência no uso de recursos.

Referências:

 Gamma, Erich, et al. Design Patterns: Elements of Reusable Object-

Oriented Software. Addison-Wesley, 1994.
 Freeman, Eric, et al. Head First Design Patterns. O'Reilly Media, 2004.

2. Qual é o papel das Fachadas na integração de

contextos limitados?
No desenvolvimento de software, a Fachada (Facade) é um design pattern
estrutural que proporciona uma interface simplificada para um subsistema
complexo. A ideia principal é ocultar as complexidades de um sistema e expor
apenas o necessário, facilitando a interação com ele.

Na integração de contextos limitados, as Fachadas desempenham um papel

fundamental ao atuar como intermediárias que simplificam a comunicação
entre diferentes partes do sistema. Elas ajudam a:

 Reduzir a Complexidade: Ao fornecer uma interface mais simples e

coesa, a Fachada oculta a complexidade subjacente das interações
entre subsistemas.
 Facilitar a Integração: As Fachadas tornam mais fácil integrar
diferentes módulos ou serviços, pois oferecem uma interface unificada.
 Proteger o Sistema Interno: Ao limitar o acesso direto aos subsistemas
internos, as Fachadas protegem o sistema de mudanças e
inconsistências externas.
Por exemplo, no contexto do Pet Friends, uma Fachada pode ser utilizada para
integrar os serviços de agendamento de consultas veterinárias. Em vez de os
clientes interagirem diretamente com os sistemas de veterinários, clientes e
agendas, a Fachada oferece uma interface simplificada que lida com toda a
lógica de integração e comunicação. Isso não apenas simplifica o processo
para os usuários finais, mas também mantém a integridade e a segurança do
sistema.

Referências:

 Gamma, Erich, et al. Design Patterns: Elements of Reusable Object-

Oriented Software. Addison-Wesley, 1994.
 Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-
Wesley, 2002.

3. Como o Domain-Driven Design (DDD) auxilia

na gestão da complexidade de projetos de
software?
O Domain-Driven Design (DDD) é uma abordagem que auxilia na gestão da
complexidade dos projetos de software ao focar no domínio do problema e na
lógica de negócios. DDD segmenta o sistema em contextos delimitados
(bounded contexts), cada um representando uma parte específica do negócio,
o que facilita a compreensão e o gerenciamento do sistema como um todo.

Ao utilizar DDD, podemos:

 Isolar Complexidade: Dividindo o sistema em contextos menores e

mais gerenciáveis.
 Facilitar a Comunicação: Utilizando uma linguagem ubíqua que é
compreendida por todos os membros da equipe, desde desenvolvedores
até stakeholders.
 Promover a Coesão: Assegurando que cada contexto delimitado tenha
uma responsabilidade clara e bem definida.
 Reduzir Acoplamento: Permitindo que diferentes partes do sistema
evoluam de forma independente.
Referências:

 Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of

Software. Addison-Wesley, 2003.
 Vernon, Vaughn. Implementing Domain-Driven Design. Addison-Wesley,
2013.

4. Explique a diferença entre design estratégico e

tático.
O design estratégico e o design tático são duas abordagens complementares
no DDD:
  Design Estratégico: Foca na visão geral do sistema, definindo os
contextos delimitados e as interações entre eles. Ele lida com a divisão
do domínio em subdomínios, estabelecendo os limites de cada contexto
e identificando as relações entre eles. O objetivo é criar uma arquitetura
robusta e bem estruturada que suporte a evolução do sistema a longo
prazo.
 Design Tático: Lida com a implementação detalhada dentro desses
contextos delimitados. Ele utiliza padrões como entidades, agregados,
repositórios e serviços para construir a lógica de negócios e as regras do
domínio. O design tático se concentra na modelagem precisa dos
elementos do domínio e na codificação das operações que manipulam
esses elementos.
Referências:

 Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of

Software. Addison-Wesley, 2003.
 Vernon, Vaughn. Implementing Domain-Driven Design. Addison-Wesley,
2013.

5. Qual é a importância da Linguagem Ubíqua,

mesmo em projetos que não usam DDD?
A Linguagem Ubíqua é fundamental para garantir uma comunicação clara e
eficaz entre todos os envolvidos no projeto, independentemente de estarem
utilizando DDD ou não. Ela estabelece um vocabulário comum que todos
entendem e utilizam, desde desenvolvedores até stakeholders, reduzindo
ambiguidades e mal-entendidos.

Em projetos que não usam DDD, a Linguagem Ubíqua ainda é importante

porque:

 Melhora a Clareza: Todos os participantes do projeto entendem os

mesmos termos e conceitos.
 Facilita a Colaboração: Equipes diferentes podem colaborar de forma
mais eficiente ao usar uma terminologia comum.
 Aumenta a Coesão: Ajuda a garantir que todos estejam alinhados
quanto aos objetivos e funcionalidades do sistema.
Referências:

 Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of

Software. Addison-Wesley, 2003.
 Vernon, Vaughn. Implementing Domain-Driven Design. Addison-Wesley,
2013.

6. O que são contextos principais, de suporte e

genéricos? Por que os contextos genéricos, em
geral, são contratados externamente?
  Contextos Principais: São centrais para o negócio e oferecem uma
vantagem competitiva. Eles são a essência do que a empresa faz e são
cruciais para a sua diferenciação no mercado. Exemplo: No Pet Friends,
o contexto de Agendamento de Serviços é um contexto principal, pois é
central para a operação do negócio.
 Contextos de Suporte: Ajudam os contextos principais a funcionar,
mas não são o foco principal do negócio. Eles suportam as operações
centrais sem serem diretamente responsáveis por gerar valor diferencial.
Exemplo: O contexto de Atendimento ao Cliente pode ser considerado
de suporte.
 Contextos Genéricos: São comuns a várias empresas e não
diferenciam o negócio. Eles tratam de funcionalidades que não são
exclusivas ou críticas para o modelo de negócios da empresa. Exemplo:
Sistemas de pagamento ou contabilidade.
Contextos genéricos são frequentemente contratados externamente porque:

 Redução de Custos: É mais barato utilizar soluções prontas e

comprovadas do que desenvolver internamente.
 Confiabilidade: Soluções genéricas terceirizadas são geralmente bem
testadas e confiáveis.
 Foco no Core Business: Permite que a empresa concentre seus
esforços em desenvolver e melhorar seus contextos principais, que
realmente diferenciam o negócio.
Referências:

 Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of

Software. Addison-Wesley, 2003.
 Vernon, Vaughn. Implementing Domain-Driven Design. Addison-Wesley,
2013.
Estratégias para Comunicações/Integrações
entre Contextos
Para assegurar uma integração eficaz entre o contexto de Agendamento de
Serviços e os contextos relacionados do Pet Friends, podem ser adotadas
diversas estratégias:

1. Padrão de Eventos: Utilizar um padrão de eventos assíncronos para

comunicação entre os contextos. Por exemplo, quando um serviço é
agendado ou modificado, um evento é disparado e os contextos
interessados podem reagir a esse evento.
2. APIs Restful: Implementar APIs RESTful para permitir a integração
direta e a consulta de informações entre os diferentes contextos. Por
exemplo, o contexto de Venda de Produtos pode consultar os horários
disponíveis para agendamento via API REST.
3. Padrão de Mensagens: Utilizar um sistema de mensagens assíncronas,
como RabbitMQ ou Kafka, para troca de informações entre os contextos.
Por exemplo, informações sobre agendamentos podem ser enviadas
através de mensagens para atualizar o estado nos contextos
relacionados.
4. Integração de Banco de Dados: Compartilhar um banco de dados ou
utilizar mecanismos de replicação de dados para permitir que os
contextos compartilhem informações críticas em tempo real. Por
exemplo, informações de clientes e horários disponíveis podem ser
compartilhadas entre Agendamento de Serviços e Atendimento ao
Cliente.
5. Gerenciamento de Transações Distribuídas: Utilizar padrões como
Saga ou Coordination para garantir que as operações que envolvem
múltiplos contextos sejam atomicamente consistentes.

Tipos de Comunicações entre Contextos

 Cliente-Fornecedor (Customer-Supplier): O contexto de
Agendamento de Serviços atua como fornecedor de serviços agendados
para os contextos de Venda de Produtos, Assinatura de
Ração/Produtos, Serviços Veterinários e Tosa e Banho, Passeio.
 Eventos Assíncronos: Eventos são utilizados para notificar mudanças
nos agendamentos, permitindo que outros contextos reajam a essas
mudanças de forma assíncrona.
 Consulta via APIs: Os contextos como Venda de Produtos e Serviços
Veterinários consultam APIs do contexto de Agendamento de Serviços
para obter informações atualizadas sobre disponibilidade e
agendamentos.
 Atualizações de Estado por Mensagens: Mensagens são usadas para
atualizar o estado dos agendamentos em diferentes contextos de forma
consistente e assíncrona.
Diferença entre Entidade e Objeto de Valor
usando Pet Friends
 Entidade: Uma entidade possui identidade única e pode ser distinguida
ao longo do tempo. No Pet Friends, um exemplo de entidade
seria Cliente. Cada cliente possui um ID único que o identifica no
sistema.
 Objeto de Valor: Um objeto de valor não possui identidade própria além
de seus atributos. No Pet Friends, um exemplo de objeto de valor
seria Horário de Agendamento, que descreve um horário específico para
um serviço e não possui identidade própria além de pertencer ao
contexto de agendamento.

Modelagem de Agregados no Contexto de

Agendamento
No contexto de Agendamento de Serviços do Pet Friends, podemos identificar
os seguintes agregados:

1. Agregado de Serviço:
 Entidades: Horário de Agendamento, Serviço
 Objetos de Valor: Tipo de Serviço (banho, tosa, consulta),
Horário de Agendamento
2. Agregado de Cliente:
 Entidades: Cliente
 Objetos de Valor: Informações de Contato, Endereço
3. Agregado de Veterinário:
 Entidades: Veterinário
 Objetos de Valor: Especialidade, Horários Disponíveis
Cada um desses agregados encapsula um conjunto de entidades e objetos de
valor relacionados, permitindo que operações e transações sejam tratadas de
forma consistente dentro de seus limites.