Visão Geral

Este curso de Arquitetura para Desenvolvedores de Software é direcionado a equipes que precisam obter um forte entendimento das boas práticas de planejamento estratégico para garantir um ciclo de vida de desenvolvimento sustentável e bem-sucedido.

Trata-se de arquitetura para desenvolvedores - em oposição a "Arquiteto como função". 

Você aprenderá sobre a importância de construir um senso de propriedade para decisões técnicas entre toda a equipe - então, quer você seja um programador júnior ou um engenheiro sênior, vamos ajudá-lo a definir um conjunto de práticas que aprimora todos os estágios de sua projeto de software e ciclo de vida da versão.

Este curso baseado em teoria amplamente independente de plataforma inclui muita discussão e é altamente adequado para personalização - para que possamos falar sobre os problemas do mundo real enfrentados por sua equipe e sua empresa.

Objetivo

Após realizar este Curso Architecture for Developers, você será capaz de:

• O que realmente queremos dizer com Arquitetura de Software?
• Compreendendo a função de arquiteto de software
• Gerenciando e mitigando riscos
• Técnicas úteis de visualização - diagramas, UML
• Boas práticas de documentação
• Ferramental

Publico Alvo

O público-alvo são os desenvolvedores de software de todos os níveis técnicos, com o objetivo de trazer um entendimento comum de boas práticas para toda a equipe. 

Também podemos personalizar a entrega e focar em tópicos específicos do plano de estudos para cursos internos, para também acomodar outras pessoas que trabalham em uma função de entrega de software - por exemplo, testadores, desenvolvedores / administradores de banco de dados, analistas de negócios, gerentes de projeto.

Pre-Requisitos

• O ideal é que os participantes tenham pelo menos o básico de experiência em um ambiente de desenvolvimento de software

Materiais

Conteúdo Programatico

Architecture

1. What is “software architecture”?
2. Architecture as a noun - structure
3. Architecture as a verb - vision
4. Types of architecture
5. Towards a definition of “software architecture”
6. Enterprise architecture - strategy rather than code
7. Developers and their interaction within TOGAF
8. Architecture domains: Business, Application, Data and Technology
9. The Developer and Agile
10. Architecture vs design
11. Is software architecture important?
12. Does every software project need software architecture?
13. Architectural drivers
14. Functional requirements
15. Quality Attributes (non-functional requirements)
16. Defining the project scope
17. Architecture Principles

Architects

1. The software architecture role
2. Architectural drivers
3. Designing software
4. Technical leadership
5. Quality assurance
6. Technical leadership
7. SCRUM, Kanban and DevOps
8. Collaborative technical leadership is not easy
9. Do agile teams need software architects?
10. Mind the gap: Gap analysis techniques
11. Software architects and coding
12. A step back in time
13. Should software architects write code?
14. The tension between coding and being senior
15. Software as an engineering discipline
16. The skills and knowledge of a software architect
17. Technology skills
18. Soft skills
19. Domain knowledge
20. Domain-driven design and bounded context
21. The developer as architect in an agile context

Architecting

1. Managing technical risks
2. Quantifying and prioritising risks
3. Identifying risks
4. Mitigating risks
5. Risk ownership
6. Software architecture in the delivery process
7. The conflict between agile and architecture
8. Technical vs functional design
9. Software architecture provides boundaries
10. How much up-front design should you do?
11. Avoid big up-front design
12. Contextualising just enough up-front design
13. Introducing software architecture
14. The essence of software architecture
15. Separation of concerns: The API
16. Microservice Architecture
17. Contract-first development
18. Migrating the Monolith

Approach

1. We have a failure to communicate
2. What happened to SSADM, RUP, UML, etc?
3. A lightweight approach
4. Moving fast requires good communication
5. Where do we start?
6. Common problems
7. The hidden assumptions of diagrams
8. A shared vocabulary
9. Common abstractions over a common notation
10. Static and dynamic structure
11. Software systems
12. Containers. (example: Docker)
13. Container orchestration. (example: Kubernetes)
14. Components vs classes
15. Non-OO components
16. Modules and subsystems
17. Platforms, frameworks and libraries

Visualisation - Diagrams Overview

1. UML or SysML usage
2. Use Case diagram
3. Sequence diagram
4. Process analysis: BPMN diagrams to the rescue
5. Component diagram
6. Class diagram
7. Deployment diagram
8. Package diagram
9. Developers and ArchiMate

Document

1. Working from a Product backlog
2. Interpreting User stories and acceptance criteria
3. Behaviour-driven design
4. The code doesn’t tell the whole story
5. Our duty to deliver documentation
6. Lightweight, supplementary documentation
7. Describe what you can’t get from the code
8. Product vs project documentation
9. Keeping documentation up to date
10. Documentation length
11. Functional Overview
12. Constraints
13. Software Architecture
14. Infrastructure Architecture
15. Deployment
16. Operation and Support
17. Development Environment
18. Decision Log

Tooling

1. The Developer and DevOps
2. Interacting with a deployment pipeline
3. Infrastructure as code, using cloud.
4. You build it, you run it!
5. Choosing a suitable Case tool
6. Sketches, diagrams, models and tooling
7. Reverse-engineering the software architecture model
8. Architecture description languages
9. Minimise the model-code gap
10. UML: final thoughts
11. Exploring your software architecture model
12. Dependency maps
13. Component size or complexity
14. Agile, evolvable Architecture