[ES] Add content skeleton (#1024)

content/es/0003-code-coverage.md

@@ -23,6 +23,8 @@ vantagens e desvantagens:
 - [**_Condition Coverage_**](color:yellow)
 - [**_Path Coverage_**](color:blue)
 
+<!-- TODO: colocar exemplo visual de código com grafo de flow para explicar as coverages -->
+
 ## Statement Coverage
 
 :::warning[Secção Incompleta]

content/es/0004-refactoring-and-reuse.md

@@ -0,0 +1,75 @@
+---
+title: Refactoring e Reutilização de Software
+description: >-
+  Refatorização e Reutilização de Software
+path: /es/refactoring
+type: content
+---
+
+# Refactoring e Reutilização de Software
+
+```toc
+
+```
+
+## Reutilização de Software
+
+Software pode ser reutilizado de várias formas:
+
+**Libraries**: adaptam através de parametrização, reutilizam código
+
+**Frameworks**: adaptam através de extensão, reutilizam design
+
+- Em _libraries_, o nosso código invoca o da _library_, que por sua vez executa e devolve controlo ao nosso programa
+
+- No entanto, em _frameworks_, ao reutilizarmos o design, utilizamos a framework como um esqueleto do programa, no qual o nosso código é incorporado. Assim, damos o _flow control_ do programa à framework. Este princípio de delegação de controlo à framework é chamado de _Hollywood Principle: "Don't call us, we'll call you"_, embora seja também conhecido como o princípio de inversão de controle (_Inversion of Control_).
+
+**Code generators**: adaptam através da escrita de modelos e frases de alto nível, geram código e possibilitam _aspect-oriented development_ (e.g. JPA) e _model-driven engineering_ (e.g. OutSystems)
+
+**Product Lines**: adaptam por seleção e extensão, com módulos comuns e módulos de variação
+
+**Services**: adaptam através de parametrização, sendo a diferença destes e das bibliotecas, que estes partilham serviços
+
+## Refactoring (Refatoração)
+
+### Processo de Refactoring
+
+As abstrações dependem do contexto, e é difícil desenvolver boas abstraçẽs através de abordagens _top-down_.
+Refactoring, é uma abordagem _bottom-up_ para a construção de abstrações a partir de casos de uso de código.
+
+O processo de refactoring é precedido pelos seguintes passos:
+
+1. Desenvolver testes para a funcionalidade que vai ser implementada.
+2. Foco em implementar a funcionalidade corretamente, sem pensar na estrutura ótima.
+3. Quando a funcionalidade estiver corretamente implementada e todos os testes passarem, podemos iniciar o processo de refactoring.
+
+O processo de refactoring é caraterizado pelo seguinte ciclo:
+
+1. Mudar a estrutura
+2. Testar
+
+:::tip[NOTA IMPORTANTE]
+
+- A refatoração é um processo incremental. É importante que se façam mudanças pequenas de cada vez, para que o código **NUNCA** deixe de funcionar.
+
+:::
+
+### Tipos de Refactoring
+
+:::warning[Secção Incompleta]
+Esta secção encontra-se incompleta. Procuram-se contribuidores.
+:::
+
+- **Test Driven Development**
+
+- **Litter-Pickup**
+
+- **Comprehension**
+
+- **Preparatory**: "make the change easy, then make the easy change"
+
+- **Planned**
+
+- **Long-Term**: substituir uma abstração com uma nova interface
+
+<!-- TODO: insert link for refactoring example movie rental -->

content/es/0005-software-design.md

@@ -0,0 +1,91 @@
+---
+title: Design de Software
+description: >-
+  Princípios e Padrões do Desenho de Software.
+path: /es/software-design
+type: content
+---
+
+# Design de Software
+
+```toc
+
+```
+
+O desenho de software é uma parte crucial no desenvolvimento de software.
+Alguns dos objetivos são facilitar a manutenção e evolução do software ao longo do tempo.
+
+O custo de mudança é altamente impactado pela localidade e propagação da mudança.
+É mais fácil mudar 100 linhas num módulo do que 1 linha em 100 módulos.
+
+Então, é necessário ficarmos familiarizados com dois conceitos cruciais de bom desenho de software:
+
+**Coesão**, ou _Cohesion_, é a métrica que avalia a localidade da mudança.
+Um módulo altamente coeso, probabilisticamente falando, terá uma localidade de mudança alta.
+
+**Ligação**, ou _Coupling_, é a métrica que avalia a propagação da mudança.
+Um módulo com baixa ligação, probabilisticamente falando, terá menor propagação de mudanças.
+
+Bom desenho de software deve ser desenvolvido com as seguites propriedades:
+
+- Alta Coesão -> Aumentar localidade de mudança
+- Baixa Ligação -> Diminuir propagação de mudança
+
+## Princípios de Design de Software
+
+Os princípios de desenho de software **SOLID** são:
+
+**S**ingle Responsibility: Um módulo deve ter uma única responsabilidade.
+
+**O**pen-Closed: Aberto a extensão, Fechado a modificação.
+
+**L**iskov's Substitution Principle: Deve ser possível substituir completamente uma subclasse pelas suas abstrações sem gerar erros.
+
+**I**nterface Segregation: Clientes devem usar interfaces mínimas que têm apenas o estritamente necessário para a sua interação.
+
+**D**ependency Inversion: Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.
+
+## Padrões de Design de Software
+
+<!-- TODO: adicionar imagens de cada padrão, para conseguirem ser explicados melhor -->
+
+### Command
+
+_Invoker_ interage com uma abstração de um comando. O cliente define um comando concreto, que implementa a interface abstrata do comando.
+
+Propriedades:
+
+- Baixa ligação entre o _invoker_ e cada comando concreto
+- Fácil de extender com novos tipos de comandos
+- Comandos concretos são altamente
+
+### Template Method
+
+Define o esqueleto do programa num algoritmo e delega alguns passos para as subclasses. Mantém a estrutura do algoritmo, com a liberdade de poder alterar os seus passos.
+
+Propriedades:
+
+- Ligação alta entre subclasses e superclass devido à estrutura do algoritmo
+- Estrutura do algoritmo é coesa na superclasse
+- Partes do algoritmo são coesas nas subclasses
+
+### Composite
+
+Compõe objetos em estruturas de árvore, com maior liberdade na representação de hierarquias.
+
+Propriedades:
+
+- Baixa ligação entre o cliente e o _composite_, pois o cliente depende de uma interface comum a todos os membros
+- Membros usam a mesma interface na comunicação, e é fácil extender com novos tipos de membros
+- Alta coesão visto que cada membro contém resposabilidades associadas à sua função
+
+### State
+
+Encapsula comportamentos variados no mesmo objeto, com base num estado interno.
+Um _State_ é uma interface abstrata usada pelo contexto, e cada _Concrete State_ é uma subclasse desta abstração.
+
+Propriedades:
+
+- Baixa ligação entre o contexto e o _State_
+- Um _Concrete State_ tem uma coesão alta relativamente ao seu set de operações
+- Operações têm baixa coesão, visto que estão divididas pelos múltiplos possíveis _Concrete States_

content/es/0006-software-architecture.md

@@ -0,0 +1,59 @@
+---
+title: Arquitetura de Software
+description: >-
+  Arquitetura de Software, Padrões Arquiteturais, Arquiteturas de Aplicações, Engenharia de Requisitos
+path: /es/software-architecture
+type: content
+---
+
+# Arquitetura de Software
+
+```toc
+
+```
+
+:::warning[Secção Incompleta]
+Esta secção encontra-se incompleta. Procuram-se contribuidores.
+:::
+
+A arquitetura de software tem o objetivo de fazer um design de alto nível do desenvolvimento de software. Deve demonstrar as qualidades do sistema e satisfazer os requisitos dos stakeholders.
+
+Pode ser vista de diferentes perspetivas:
+
+- Lógica (Logical view)
+- Física (Physical view)
+- Desenvolvimento (Development view)
+- Processo (Process view)
+
+## Padrões Arquiteturais
+
+**MVC**
+
+**Layered**
+
+**Repository**
+
+**Client-Server**
+
+**Pipe and Filter**
+
+## Arquiteturas de Aplicações
+
+**Transaction Processing Sytems**
+
+**Information Systems**
+
+**Language Processing Systems**
+
+## Engenharia de Requisitos
+
+Qualidades dos Requisitos:
+
+- Completude (Completeness)
+- Consistência (Consistency)
+- Mensurabilidade (Measurability)
+
+### Processo de Engenharia de Requisitos
+
+1. Elicitação e Análise
+2. Validação

content/es/0007-peaa.md

@@ -0,0 +1,129 @@
+---
+title: Padrões de Aplicações Empresariais
+description: >-
+  Padrões de Aplicações Empresariais: Lógica de Domínio, Arquitetura de Fontes de Dados, Object-Relational Structural and Behavioral, Apresentação, Distribuição
+path: /es/peaa
+type: content
+---
+
+# Padrões de Aplicações Empresariais
+
+```toc
+
+```
+
+<!-- TODO: provide examples for each pattern-->
+
+Estes são alguns dos padrões utilizados no desenvolvimento de aplicações empresariais. Mais padrões podem ser encontrados no catálogo oficial [Patterns of Enterprise Applications](https://martinfowler.com/eaaCatalog/), sendo que estes estão explicados a fundo no [livro](https://martinfowler.com/books/eaa.html).
+
+## Domain Logic Patterns
+
+### Transaction Script
+
+Organiza a lógica de domínio em transações, em que cada transação está associada a um _request_ do utilizador e trata de uma única apresentação.
+
+### Domain Module
+
+Organiza a lógica de domínio numa abordagem orientada a objetos. É caraterizada por objetos de domínio que incorporam tanto lógica de negócio como dados.
+
+### Service Layer
+
+Define limites da aplicação através de uma camada de serviços, que define um conjunto de operações/serviços que o utilizador pode executar, coordenando as respostas da aplicação para cada um desses serviços.
+
+## Data Source Architectural Patterns
+
+### Table Data Gateway
+
+Objeto que serve de _gateway_ para uma tabela da base de dados. Cada instância deste objeto está responsável pela interação com todas as linhas dessa tabela.
+
+### Row Data Gateway
+
+Objeto que serve de _gateway_ para uma linha numa tabela da base de dados. Cada instância deste objeto está responsável pela interação com uma única linha da tabela.
+
+### Active Record
+
+Objeto que encapsula uma linha de uma tabela da base the dados, adicionando lógica de domínio a esses dados.
+
+### Data Mapper
+
+Uma camada de _mappers_ que associa objetos de domínio com a base de dados, o que promove a independência entre a estrutura do objeto de domínio e a representação deste na base de dados.
+
+## Object-Relational Behavioral Patterns
+
+### Unit of Work
+
+Mantém uma lista de objetos afetados por uma transação, para coordenar a escrita das alterações da transação e resolver problemas de concorrência.
+
+### Identity Map
+
+Mapa de identidade que garante que cada objeto só é carregado uma vez. Quando tenta aceder ao objeto, verifica se não foi já carregado para o mapa.
+
+### Lazy Load
+
+Objetos que não contém toda a informação necessária, mas sabem como ir buscar, maioritariamente para melhorar a eficiência e evitar carregar objetos de largas dimensões a menos que necessário.
+
+Existem múltiplas abordagens:
+
+- **_Lazy Initialization_**: verifica se campo é _null_ quando acede, e se for _null_, carrega-o
+- **_Virtual Proxy_**: _proxy_ do objeto real que delega responsabilidade para o objeto real quando algum dos seus campos é acedido
+- **_Value Holder_**: encapsula os campos do objeto real com métodos
+- **_Ghost_**: objeto real num estado parcial, que carrega todos os campos quando acessado
+
+## Object-Relational Structural Patterns
+
+### Identity Field
+
+Guardar o ID do objeto na base de dados como um dos seus campos, para manter uma identidade entre o objeto em memória e na base de dados.
+
+### Foreign Key Mapping
+
+Associa objetos através de uma _foreign key_ que referencia a outra tabela da associação.
+
+### Association Table Mapping
+
+Associa objetos criando uma nova tabela que guarda conjuntos de _foreign keys_, em que cada uma referencia uma tabela da associação.
+
+### Single Table Inheritance
+
+Representa uma hierarquia de herança com uma única tabela, com colunas para todos os campos de todas as subclasses. Alguns objetos poderão ter colunas a _null_, associadas aos campos que não fazem parte da sua classe concreta.
+
+### Class Table Inheritance
+
+Representa uma hierarquia de herança com uma tabela para cada classe. Uma classe concreta pode resultar dos joins das tabelas das várias classes que a compõem.
+
+### Concrete Table Inheritance
+
+Representa uma hierarquia de herança com uma tabela para cada classe concreta.
+
+## Web Presentation Patterns
+
+### Model-View-Controller (MVC)
+
+Divide a interface de utilizador em 3 componentes com as suas responsabilidades, o modelo, a vista, e o controlador.
+A vista apresenta os dados ao utilizador.
+O controlador atualiza o modelo e entrega os dados à vista apropriada.
+O modelo contém os dados.
+
+O utilizador pede uma vista a um controlador. O controlador interage com o modelo, e pede os dados. O modelo devolve os dados ao controlador. O controlador entrega os dados à vista. A vista apresenta os dados ao utilizador.
+
+### Front Controller
+
+Um controlador que trata de todos os _requests_.
+
+Existe um _handler_ que trata de todo o comportamento comum e chama comandos através de uma interface _command_.
+
+Existem comandos concretos, que definem comportamento específico e herdam da interface _command_.
+Cada um destes comandos concretos é chamado pelo _handler_, executa o seu comando concreto e escolhe a vista apropriada para ser apresentada.
+
+<!-- TODO: maybe add Template View later-->
+
+## Distribution Patterns
+
+### Remote Façade
+
+Fornece uma _coarse-grained interface_ em _fine-grained objects_ para aumentar a eficiência através de uma rede.
+É mais eficiente ter menos chamadas remotas mais grosseiras e depois retirar a informação necessária dentro do processo final do que fazer múltiplas chamadas remotas finas.
+
+### Data Transfer Object (DTO)
+
+Objeto serializável que serve para transferir dados entre processos de forma prática e eficiente. É um objeto de dados, não é o próprio objeto.