Alura Anotações - Java e Clean Architecture: Descomplicando arquitetura de software

alura_java_clean_architecture.md

O que abrange à Arquitetura de Software?

From the book Documenting Software Architectures:

Views and Beyond (2nd Edition), Clements et al, AddisonWesley, 2010:

• The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both. how the elements relate to each other.

From the book Software Architecture in Practice

(2nd edition), Bass, Clements, Kazman; AddisonWesley 2003:

• This means that architecture specifically omits certain information about elements that does not pertain to their interaction.

SONI, NORD, AND HOFMEISTER, 1995:

• The conceptual architecture describes the system in terms of its major design elements and the relationships among them.
• The module interconnection architecture encompasses two orthogonal structures: functional decomposition and layers.
• The execution architecture describes the dynamic structure of a system.
• The code architecture describes how the source code, binaries, and libraries are organized in the development environment

Para organizar uma arquitetura limpa, podemos dividir a aplicação em 4 níveis

1. Domínio - Regras de negócio: - Entidades: Aluno, Funcionario, Sala
2. Casos de uso - Regras de Aplicação - Uma interface onde tem todas as ações de Alunos: Matricular, Detalhar, etc...
3. Apresentação - Matricular/Salvar aluno em memória | Matricular/Salvar aluno em um banco de dados
4. Infraestrutura / UI / Frameworks

Requisitos Funcionais

-- Como cada camada conversa uma com a outra

• Infraestrutura do Software -- Como os requisitos físicos e dados lidam com a aplicação
• Estrutura de design do código -- Organização do código
• Suporte aos requisitos de negócio -- Como o software suporta o objetivo da aplicação
• Simplificar evoluções no Software -- Como essa aplicação pode escalar e evoluir

Requisitos não funcionais

~ Performance, Escalabilidade, Disponibilidade, Confiabilidade, Segurança

Clean Architecture

• Isolar o código de domínio (regras de negócio) da aplicação, esse código existe independente da tecnologia utilizada
• Inversão de dependências?
• Favorece boas práticas de Orientação à Objetos
• Favorece código fácil e altamente testável
• Favorece Independência de frameworks

Entidades e Value Objects

• Entidades possuem uma identidade única, enquanto VOs são considerados iguais, se todos os seus atributos tiverem valores iguais.

É uma boa prática segregar as entidades em pacotes ou módulos

Uncle Bob considerations

• So what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Or do they scream: Rails, or Spring/Hibernate, or ASP?

• How can I prevent the framework from taking over that architecture.

• Your architectures should tell readers about the system, not about the frameworks you used in your system

• Inversão de dependência é fazer a camada superior (dados) depender da inferior(domínio) e não o contrário. ~ Alto nível: Caso de uso ~ Baixo nível: Domínio