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.
(2nd edition), Bass, Clements, Kazman; AddisonWesley 2003:
- This means that architecture specifically omits certain information about elements that does not pertain to their interaction.
- 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
- Domínio - Regras de negócio: - Entidades: Aluno, Funcionario, Sala
- Casos de uso - Regras de Aplicação - Uma interface onde tem todas as ações de Alunos: Matricular, Detalhar, etc...
- Apresentação - Matricular/Salvar aluno em memória | Matricular/Salvar aluno em um banco de dados
- Infraestrutura / UI / Frameworks
-- 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
~ Performance, Escalabilidade, Disponibilidade, Confiabilidade, Segurança
- 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 possuem uma identidade única, enquanto VOs são considerados iguais, se todos os seus atributos tiverem valores iguais.
-
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