Arquitetura de Software: Fatos, Mitos, Verdades

Mindmap sobre a palestra do Eduardo Pires no Canal .NEThttps://www.youtube.com/watch?v=AnAsUsukEqs

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Arquitetura de Software: Fatos, Mitos, Verdades por Mind Map: Arquitetura de Software: Fatos, Mitos, Verdades

1. O que é arquitetura

1.1. Arquitetura é a organização fundamental de um sistema em seus componentes, responsabilidade e relacionamentos com o ambiente e os princípios que conduzem seu design e evolução [ISO/IEEE 42010-2011]

1.2. Arquitetura

2. Perfis de arquitetos

2.1. Segundo a IASA(Global IT Architects Association)

2.1.1. Existem diversos perfis de arquitetos, cada um com um conjuntos de responsabilidades e focos profissionais específicos

2.2. Enterprise Architect

2.2.1. Objetivo

2.2.1.1. Garantir a estratégia do negócio com soluções em TI

2.2.2. Artefatos

2.2.2.1. Estratégias de TI, mapas de capacidade, estratégias de integração, análises as-is/to be, análise de gap

2.2.3. Conceito Chave

2.2.3.1. Alinhamento entre TI e negócios

2.3. Business Architect

2.3.1. Objetivo

2.3.1.1. Modelagem do negócio da organização entendendo os processos atuais e sugerindo melhorias

2.3.2. Artefatos

2.3.2.1. Mapa de processos, casos de uso e modelos informacionais

2.3.3. Conceito Chave

2.3.3.1. Enteder o funcionamento da organização

2.4. Solution Architect

2.4.1. Objetivo

2.4.1.1. Projetos de soluções em TI baseado nos requisitos do negócio, utilizando as capacidades de TI existentes na organização

2.4.1.1.1. exemplo

2.4.2. Artefatos

2.4.2.1. Diagrama de aplicações, mapas de sistema, interfaces de serviços, interfaces de serviços técnicos

2.4.3. Conceito Chave

2.4.3.1. Suportar a estratégia do negócio

2.5. Software Architect

2.5.1. Objetivo

2.5.1.1. Projetar aplicações utilizando conceitos de arquitetura e boas práticas de desenvolvimento

2.5.2. Artefatos

2.5.2.1. Frameworks, arquiteturas / modelos de referência, análise de cenários / desafios técnicos

2.5.3. Conceito Chave

2.5.3.1. Qualidade, Flexibilidade, Performance, Reuso, Testabilidade, Escalabilidade e Segurança

3. Responsabilidades de um arquiteto de software

3.1. Responsabilidades

3.1.1. O objetivo principal de um arquiteto de software é projetar uma solução compatível com os requisitos atuais da corporação, que tenha flexibilidade suficiente para comportar mudanças futuras e/ou novos requisitos resultantes de sua evolução ao longo do tempo

3.1.2. Ser responsável pela qualidade técnica do entregável, atuar no apoio técnico de toda equipe e ajudar nas decisĩes necessárias

3.1.3. Promover a comunicação do time, envolvendo e delegando as decisões de arquitetura com toda a equipe

3.2. Softskills

3.2.1. Comunicação

3.2.2. Responsabilidade

3.2.3. Espirito de liderança

3.2.4. Não pode ser alguem introspectivo / lowprofile

3.3. Hardskills

3.3.1. OOP

3.3.2. SOLID

3.3.3. Design Patterns

3.3.4. Testes

3.3.5. Escrita de código performático

3.3.6. Estilos e Padrões Arquiteturais

3.3.7. SQL, NoSQL, GraphQL

3.3.8. DDD

3.3.9. Cloud Architecture

3.3.10. Event Driven Architecture

3.3.11. Arquitetura Distribuída

3.3.12. Docker / Kubernetes / Service Fabric

3.3.13. MQ / Kafka

3.3.14. DevOps

3.3.15. Logging / Tracing

3.3.16. Disaster Recovery / Health Checks

4. Estilos e padrões arquiteturais

4.1. Fato #1

4.1.1. Uma arquitetura possui estilos e padrões

4.1.1.1. exemplo de engenharia civil

4.1.1.1.1. neoclássica

4.1.1.1.2. gótica

4.1.1.1.3. moderna

4.1.1.1.4. contemporânea

4.1.1.1.5. mas e isso?

4.2. Fato #2

4.2.1. Todo software possui arquitetura

4.3. O que é

4.3.1. Um estilo arquitetural é uma abordagem de projetar e entregar uma aplicação

4.3.2. Trata-se de como organizar os componentes responsáveis de uma arquitetura, como eles irão se relacionar e quais aspectos tecnológicos irão atender

4.4. Exemplos

4.4.1. Camadas

4.4.1.1. .

4.4.2. REST

4.4.2.1. .

4.4.3. Microservices

4.4.3.1. .

4.4.3.2. Não deixa de ser SOA, porém mais simples

4.4.4. Plugin

4.4.4.1. .

4.4.5. Client-Server

4.4.5.1. .

4.4.6. Pipe and Filters

4.4.6.1. .

4.5. Padrões Arquiteturais

4.5.1. Visão geral

4.5.1.1. Os Padrões Arquiteturais são semelhantes aos Design Patterns, mas possuem um escopo diferente

4.5.1.2. Os Padrões Arquiteturais são estratégias de alto nível que dizem respeito a componentes de grande escala, as propriedades e mecanismos globais de um sistema

4.5.1.3. Um projeto de arquitetura pode conter diversos estilos arquiteturais, e cada estilo arquitetural pode utilizar diversos padrões arquiteturais. Um padrão arquitetural pode ser um subconjunto de um estilo arquitetural visando um escopo especifico

4.5.1.3.1. Exemplo o padrão arquitetural MVC, não é um estilo, mas sim um padrão para um problema recorrente

4.5.1.4. Um padrão arquitetural é uma solução geral e reutilizável para um problema em um contexto particular. É uma solução recorrente para um problema recorrente

4.5.2. Exemplos

4.5.2.1. 3-Tier Architeture Famosa arquitetura 3 camadas

4.5.2.1.1. Clássica maneira de distribuir responsabilidades (apresentação, aplicação, acesso a dados)

4.5.2.1.2. Não deve ser menosprezada, pois nem sempre a complexidade é uma solução para problemas simples

4.5.2.1.3. Pode ser aplicada em diversos cenários, porém geralmente é mais encontrada em aplicações com foco comercial (cadastro, regras e etc)

4.5.2.2. CQRS - Command Query Responsibility Segregation

4.5.2.3. Event Sourcing

4.5.2.3.1. "Nós podemos buscar o estado de uma aplicação para encontrar um estado atual do mundo, e isso responde muitas perguntas. Entretanto há momento que nós não só queremos ver onde nós estamos, mas também queremos saber como chegamos lá" - Martin Fowler

4.5.2.4. Onion Architecture Famosa arquitetura Cebola - Clean Architecture

4.5.2.4.1. representação

4.5.2.5. Hexagonal Architecture "Ports & Adapters" Onion, DDD, Clean, CQRS tudo junto

4.5.2.5.1. representação

4.6. Estilos Arquiteturais

4.6.1. Structure

4.6.1.1. Component-based

4.6.1.2. Monolithic application

4.6.1.3. Layered

4.6.1.4. Pipes and Filters

4.6.2. Shared Memory

4.6.2.1. Database-centric

4.6.2.2. Blackboard

4.6.2.3. Rule-based

4.6.3. Messaging

4.6.3.1. Event-driven aka implicit invocation

4.6.3.2. publish-subscribe

4.6.3.3. asynchronous messaging

4.6.4. Adaptive Systems

4.6.4.1. plug-ins

4.6.4.2. microkernel

4.6.4.3. reflection

4.6.4.4. domain specific languages

4.6.5. Distributed Systems

4.6.5.1. client-server

4.6.5.2. shared nothing architecture

4.6.5.3. space-based architecture

4.6.5.4. object request broker

4.6.5.5. peer-to-peer

4.6.5.6. representational state transfer

4.6.5.7. service-oriented

4.6.5.8. cloud computing patterns

5. Mitos sobre DDD

5.1. Mito #1

5.1.1. DDD é arquitetura de software

5.1.1.1. DDD é uma filosofia de como pensar em desenvolver software

5.2. O que é DDD

5.2.1. é uma abordagem de modelagem de software com foco na complexidade da aplicação

5.2.2. Através do conhecimento do domínio é possível facilitar a implementação de complexas regras / processos de negócio

5.2.3. Domain Driven Design é sobre design

5.2.4. Design guiado pelo conhecimento do domínio

5.2.5. "Toda arquitetura é design, mas nem todo design é arquitetura" - Grady Booch

5.2.6. Você precisa ter conhecimento o suficiente para identificar por conta própria se deve implementar DDD ou não

5.2.6.1. Caso não esteja conseguindo identificar Não implemente

5.2.7. DDD Não é arquitetura em camadas

5.3. Processo de "Implementação" do DDD

5.3.1. Entender o negócio

5.3.2. Extrair a linguagem ubíqua

5.3.3. Modelagem estratégica

5.3.3.1. Extrair a linguagem ubíqua vai colaborar na visão e entendimento do negócio e como segregar seu domínio em partes menores e responsáveis

5.3.3.2. Para documentar estas segregações responsáveis utilizamos através de imagens e uma simples documentação do tipo de relacionamento entre os contextos

5.3.3.3. Cada contexto delimitado possui sua própria linguagem ubíqua, pois em contextos diferentes, os termos podem ter significados diferentes

5.3.3.4. context map

5.3.4. Definir a arquitetura

5.3.4.1. DDD não fala como vai ser sua arquitetura, mas vai deixar claro o contexto do problema que você está resolvendo

5.3.5. Modelagem Tática

5.3.5.1. Aggregate Object

5.3.5.1.1. Uma entidade que é a raiz agregadora de um processo do domínio que envolve mais de uma entidade

5.3.5.2. Domain Model

5.3.5.2.1. Uma entidade do domínio, possui estados e comportamentos, lógica de negócio, getters and setters, AdHoc, etc

5.3.5.3. Value Object

5.3.5.3.1. Um objeto que agrega valor ás entidades, não possui identidade e é imutável

5.3.5.4. Factory

5.3.5.4.1. Classe responsável por construir adequadamente um objeto / entidade

5.3.5.5. Domain Service

5.3.5.5.1. Serviço do domínio que atende partes do negócio que não se encaixam em entidades específicas, trabalha com diversas entidades, realiza persistência através de repositórios e etc

5.3.5.6. Application Service

5.3.5.6.1. Serviço de aplicação que orquestra ações disparadas pela camada de apresentação e fornece DTOs para comunicação entre as demais camadas e para o consumo da camada de apresentação

5.3.5.7. Repository

5.3.5.7.1. Uma classe que realiza a persistência das entidades se comunicando diretamente com o meio de acesso aos dados, e utilizando apenas um repositório por agregação

5.3.5.8. External Service

5.3.5.8.1. Serviço externo que realiza a consulta/persistência de informações por meios diversos

5.3.5.9. representação

5.3.6. representação

5.4. Mito #2

5.4.1. Monólitos são ultrapassados

6. A lenda dos Microservices

6.1. Conway's Law

6.1.1. "Qualquer empresa que projeta um sistema, inevitavelmente produz um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização" - Melvin Conway

6.1.1.1. .

6.2. 10 motivos para não adotar arquitetura de microsserviços

6.3. A sua empresa possui o mesmo porte da Netflix, Google, Microsoft, Uber, Amazon, etc?

6.4. A sua empresa possui diversos times com profissionais extremamente qualificados e multidisciplinares?

6.5. A sua empresa fatura bilhões por ano e dispõe de um grande budget para projetos e pesquisa?

6.6. A sua empresa já chegou na fase de maturidade na entrega de software, aplica boas práticas, trabalha com agilidade, inclusive utilizando técnicas DevOps?

6.7. Se as respostas forem tudo não

6.7.1. então sempre considere a complexidade!

6.7.2. Complexidades

6.7.2.1. Acidental

6.7.2.1.1. A complexidade acidental é aquela que surge durante o processo de desenvolvimento, ou seja, ela é CAUSADA pela abordagem escolhida para resolver o problema

6.7.2.2. Essencial

6.7.2.2.1. Já a essencial é basicamente a complexidade que nosso "software" se propõe resolver SIM, infelizmente existem problemas complexos, e é neles que temos que focar

6.8. "Um arquiteto permite que decisões importantes sejam adiadas, um bom arquiteto máxima o número de decisões não tomadas" - Uncle Bob

6.9. Microservices, Serverless, Aplicações Distribuídas, DDD e etc... É para quem PRECISA

6.10. E não tem problema descobrir que precisava só depois de ter feito sem. Projetos e arquiteturas evoluem! O problema é implementar a complexidade, sem precisar e as vezes até mesmo sem saber como fazer direito

7. Como pensar em uma arquitetura compatível com sua necessidade

7.1. Analise quais são os principais desafios

7.2. quais desses desafios implicam em utilizar uma determinada tecnologia, como REST, Message Brokers, etc

7.3. Precisa entender o problema, para que com suas ferramentas, resolver o problema, então tenha varias ferramentas

7.4. Qual é a estratégia da empresa, para saber se os projetos vão ser muito alterados, se o concorrente se atualiza muito e você também

8. Arquiteturas evolutívas

8.1. Lembre-se que

8.1.1. .

8.2. o que é?

8.2.1. Evolui de uma arquitetura mais simples para outras mais complexas, como:

8.2.1.1. monolithic, para

8.2.1.1.1. service-oriented, para

9. O que é necessário para se tornar um arquiteto

9.1. Só o tempo vai te transformar em um arquiteto

9.2. além do conhecimento, a experiência só o tempo vai te ajudar

9.3. escolha bem seus desafios, pois uma empresa que não anda, não vai te ajudar

10. Dicas de leitura

10.1. You can be a software Architecture

10.2. Clean Code

10.2.1. Robert C. Martin

10.3. The Clean Coder

10.3.1. Robert C. Martin

10.4. Clean Architecture

10.4.1. Robert C. Martin

10.5. Clean Agile

10.5.1. Robert C. Martin

10.6. Computer Science

10.6.1. Robert Sedgewick, Kevin Wayne

10.7. Implementing Domain-Driven Design

10.7.1. Vaughn Vernon

10.8. Pattern of enterprise Application Architecture

10.8.1. Martin Fowler

10.9. Domain-Driven Design

10.9.1. Erick Evans

10.10. Domain-Driven Design Distilled

10.10.1. Vaughn Vernon

11. Dicas de Cursos