Fundamentos de Arquitetura de Software
Eduardo Pires é fundador da plataforma desenvolvedor.io, arquiteto e desenvolvedor de software, palestrante e instrutor de treinamentos.
Foi reconhecido como Most Valuable Professional (MVP) pela Microsoft na competência de desenvolvimento de software de 2014 até 2020.
Este reconhecimento é um prêmio internacional conferido pela Microsoft aos profissionais de maior destaque no mercado, existem cerca de 3.500 MVPs no mundo e 110 MVPs no Brasil, sendo 40 deles na competência de desenvolvimento de software.
- Apresentação (1:00)
- O que é arquitetura? (15:00)
- Perfis de arquitetos (6:00)
- Arquiteto Corporativo (7:00)
- Arquiteto de Negócios (6:00)
- Arquiteto de Soluções (6:00)
- Arquiteto de Software (11:00)
- Outros perfis de arquitetos (3:00)
- Responsabilidades (7:00)
- Requisitos Técnicos (8:00)
- Requisitos Pessoais (14:00)
- Mitos sobre o Arquiteto de Software (11:00)
- Pilares da Programação Orientada a Objetos (4:00)
- Estado e Comportamento (7:00)
- Herança (6:00)
- Abstração (4:00)
- Polimorfismo (9:00)
- Encapsulamento (20:00)
- Interface x Implementação (10:00)
- Herança x Composição (17:00)
- Teste seus conhecimentos - Herança (3:00)
- Teste seus conhecimentos - Abstração (5:00)
- Teste seus conhecimentos - Polimorfismo (4:00)
- Teste seus conhecimentos - Encapsulamento (5:00)
- Teste seus conhecimentos - OOP (4:00)
- Princípios SOLID (10:00)
- SRP - Single Responsability Principle (13:00)
- OCP – Open Closed Principle (15:00)
- LSP- Liskov Substitution Principle (20:00)
- ISP - Interface Segregation Principle (8:00)
- DIP - Dependency Inversion Principle (18:00)
- Teste seus conhecimentos - SRP (3:00)
- Teste seus conhecimentos - OCP (4:00)
- Teste seus conhecimentos - LSP (4:00)
- Teste seus conhecimentos - ISP (3:00)
- Teste seus conhecimentos - DIP (4:00)
- Exemplo do "mundo real" (16:00)
- Tipos de ciclo de vida (17:00)
- Registro de generics (7:00)
- Property Injection (8:00)
- Service Locator "Pattern" (11:00)
- N Classes : 1 Interface (10:00)
- Teste seus conhecimentos (3:00)
- Apresentação (4:00)
- O que é um código limpo? (4:00)
- Desculpas e responsabilidades (25:00)
- Como medir um bom código? (13:00)
- Boas práticas (13:00)
- Devo comentar meu código? (7:00)
- Tratamento de erros (10:00)
- Apresentação (8:00)
- Creational Patterns (6:00)
- Abstract Factory (21:00)
- Factory Method (12:00)
- Singleton (14:00)
- Structural Patterns (6:00)
- Adapter (10:00)
- Facade (15:00)
- Composite (14:00)
- Behavorial Patterns (7:00)
- Command (15:00)
- Strategy (12:00)
- Observer (11:00)
- Evite o Patternite (4:00)
- Estilos Arquiteturais (13:00)
- Padrões Arquiteturais (6:00)
- 3-Tier Architecture (4:00)
- Onion Architecture (9:00)
- Hexagonal Architecture "Ports & Adapters" (22:00)
- CQRS - Command Query Responsibility Segregation (16:00)
- Event Sourcing (10:00)
- DDD - Domain-Driven Design (30:00)
- Arquiteturas Evolutivas (10:00)
- Sempre considere a complexidade! (7:00)
- Conway's Law (9:00)
- Agilidade e o Manifesto Ágil (15:00)
- DevOps (12:00)
- Principios DRY, KISS e YAGNI (10:00)
- Leituras recomendadas (7:00)
- Palavras finais (6:00)
Indicado para aplicações complexas, com muitas entidades e regras de negócio.
Razoavelmente fácil de enetender, difícil de aplicar.
É um guia de como entender um negócio, organizá-lo em conjunto de princípios, cirar uma modelagem com base no negócio e implementar utilizando diversas boas práticas.
O primeiro passo é entender o negócio juntamente com um "Domain Expert" (pessoa responsável pelo negócio), as vezes essa pessoa também assume o papel de "Product Owner", ou algum outro papel desde que ele se denomine o responsável pelo negócio.
Essa pessoa vai te guiar, vai estar 100% disponível para tirar dúvidas, até mesmo para definir novos modelos de negócio, novas regras, nomear coisas.
É um vocabulário de todos os termos específicos do domínio
- nomes, verbos, adjetivos, jargões, apelidos, expressões idiomáticas e advérbios
Compartilhado por todas as partes envolvidas no projeto
- Primeiro passo para evitar desentendimento
Usada em todas as formas faladas e escritas de comunicação
- A linguagem universal de um negócio é feita dentro da empresa
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 reponsáveis.
Para documentar estas segregações responsáveis utilizando o Mapa de Contextos (Context Map) que pode ser representado através de imagens e uma simples documentação do tipo de relacionamento entre os contextos.
Cada contexto delimitado possui sua própria Linguagem Ubíqua, pois em contextos diferentes, os termos podem ter significados diferentes.
"No modelo de domínio o contexto muda a forma de como o produto é visto / de como o produto é trabalhado. (exemplo do produto no modelo de negócios 'produto representa a mesma coisa em todos os contextos' e no exemplo o produto é diferente em cada contexto 'produto em marketing context é diferente de sales context, que é diferente de pricing context, etc.')"
Context Map: a ideia de como vai funcionar o domínio
Falar de tecnologia, divisões em camadas e modelagem na forma técnica.
Definir como vão funcionar os subdomínios / contextos.
Uma entidade que é a raiz agregadora de um processo de domínio que envolve mais de uma entidade.
Uma entidade do domínio, possui estados e comportamentos, lógica de negócio, getters e setters AdHoc, etc.
Um objeto que agrega valor às entidades, não possui identidade e é imutável.
Classe responsável por construir adequadamente um objeto / entidade.
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.
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.
Uma classe que realiza a persistência das entidades se comunicando diretamente com o meio de acesso aos dados, é utilizado apenas um repositório por agragação.
Serviço externo que realiza a consulta/persistência de informações por meios diversos.
"Processo do Domain Driven Design é para que você possa ter essa entrega (aplicação funcionando), não é apenas para 'simplesmente criar camadas de aplicação, domínio e pronto'. O DDD é você pensar no negócio do começo ao fim. Fazer as perguntas certas, extrair a linguagem ubíqua, depois fazer a modelagem estratégica, para depois pensar na arquitetura, para depois pensar na modelagem tática, se você não seguir esses passos você provavelmente vai errar!"
Don't Repeat Yourself
Keep It Simple, Stupid
You Ain't Gonna Need It
- Clean Code - Robert C. Martin
- Clean Coder - Robert C. Martin
- Clean Architecture - Robert C. Martin
- Patterns of Enterprise Application Architecture - Martin Fowler
- Computer Science - Robert Sedgewick Kevin Wayne
- Domain-Driven Design - Eric Evans
- Implementing Domain Driven Design - Vaugh Vernon
- Domain-Driven Design Distilled - Vaughn Vernon
01 - TOGAF - Framework de Arquitetura
04 - IASA - Architects Association
05 - Zachman - Enterprise Architecture
06 - BPMN - Business Process Model and Notation
07 - Catalogo Web de Design Patterns