Forem: Igor Oliveira

Uma Abordagem Funcional para Domain-Driven Design

Igor Oliveira — Fri, 28 Nov 2025 00:43:14 +0000

Há algumas semanas, eu defini a meta de aprender TypeScript e desenvolver um produto do zero utilizando tudo o que a linguagem de programação tem a oferecer. Sendo alguém com experiência trabalhando com orientação a objetos, migrar para um ambiente multiparadigma me pareceu bastante interessante. Um dos desafios foi trazer os conceitos aplicados em aplicações C# e .NET para o mundo do Node.js, e um desses conceitos foi o Domain-Driven Design.

Explicando de forma breve, Domain-Driven Design, ou DDD, é uma abordagem de desenvolvimento de software que foca na complexidade do domínio de negócio, trazendo-o para o centro do desenvolvimento e buscando aproximar os especialistas desse domínio do processo de criação dos sistemas. Ele te fornece algumas ferramentas para lidar melhor com essa complexidade.

Dentro dessa abordagem, você encontra o Design Estratégico: ele lida com a visão macro, com a estrutura do domínio, com os limites do negócio e com o vocabulário dos especialistas. É aqui que se trabalha com Mapas de Contexto, Contextos Delimitados, subdomínios, Domínio Básico, Domínio de Suporte, Domínio Genérico e Linguagem Ubíqua. Já o Design Tático entra na parte “concreta” da modelagem dentro de cada Bounded Context. É aqui que lidamos com Entidades, Objetos de Valor, Eventos de Domínio, entre outros.

Os padrões estratégicos se adaptam bem a qualquer linguagem, por isso, o foco do texto será exclusivamente no Design Tático.

O TypeScript fornece suporte a classes — não tão ricas quanto no C#, mas bastante flexíveis de trabalhar. E, enquanto desenvolvia um projeto eu pensei: utilizando em uma linguagem multiparadigma, é possível trabalhar com DDD incorporando elementos da programação funcional? E a resposta é sim!

Um dos meu livros de referência Implementando Domain-Driven Design, o foco do DDD Tático fica em linguagens orientadas a objetos, o que me fez buscar outras fontes. Dentre vários artigos lidos (referências ao final da página), cheguei a um projeto simples, mas bastante didático, adaptando conceitos e tentando criar algo a partir disso para quem, assim como eu, também tem essa dúvida.

Entidades e Regras de Negócio

No DDD orientado a objetos, as entidades são normalmente classes possuindo estado e comportamento. Regras e invariantes tendem a ficar dentro das classes de domínio. Esse estilo usa construtores, métodos de instância e encapsulamento por visibilidade (private). Em uma abordagem funcional, a ideia é separar os dados (tipos imutáveis) de comportamentos (funções puras). Em vez de métodos que mutam, temos funções que recebem dados e retornam novos dados ou outcomes.

type BaseEntity<T> = T & { Id: number, IsActive: boolean };

export type User = BaseEntity<{
    Username: string,
    Email: string, 
    Password: string,
    PhoneNumber: string,
    Address: Adderss
}>;

Quando falamos de funções puras, um conceito importante são as Invariants. Em matemática, um invariante é uma propriedade de um objeto matemático que permanece inalterada após a aplicação de operações ou transformações de determinado tipo sobre esse objeto. No nosso caso, esse conceito se aplica a funções pequenas (predicates) que respondem perguntas atômicas do domínio, ex.: isPasswordStrong, isAddressInCoverage

export const IsValidEmail = (email: string) : boolean =>  emailPattern.test(email);
export const IsValidPassWord = (password: string) : boolean => passwordPattern.test(password);
export const IsUserActive = (isActive: boolean) : boolean => isActive === true;

Outro conceito importante são os Derivers. Eles formam o núcleo funcional do sistema, concentrando as regras de negócio puras. São compostos por invariantes e têm como resultado um Outcome (uma discriminated union) ou um novo delta/novo. Eles não realizam I/O, não criam entidades finais e não fazem persistência.

O Deriver faz apenas duas coisas (dependendo do caso):

Decidir: responde à pergunta “pode/como essa operação acontecer?” retornando um Outcome (ex.: INVALID_EMAIL, WEAK_PASSWORD, SUCCEEDED).
Derivar estado: calcular um novo estado/delta a partir dos dados (ex.: calcular passwordHash, normalizar email, calcular novo carrinho) — Transform Deriver.

const DeriveUser = async (dto: UserDtoType) : CreateUserOutcome => {
    if(IsValidEmail(dto.Email))
        return { outcome: "INVALID_EMAIL" }
    if(IsValidPassWord(dto.Password))
        return { outcome: 'INVALID_PASSWORD' }
    return { 
        outcome: 'SUCCEEDED',
        payload: {
            normalizedEmail: dto.Email,
            hashedPassword: await HashPassword(dto.Password),
            username: dto.Username
        }
     }
}

Quando falo em “derivar um novo estado” não quero dizer “aplicar esse novo estado ao banco/sistema”. O Deriver retorna um valor (novo objeto em memória) que representa como o estado deveria ficar. Persistir esse novo estado é responsabilidade do Handler.

Outcome: union discriminado que descreve todas as possibilidades de resultado. É o contrato pelo qual o Deriver comunica decisões ao Handler. Exemplo:

export type UserOutcome =
  | { outcome: "INVALID_EMAIL" }
  | { outcome: "INVALID_PASSWORD" }
  | { outcome: "INVALID_PHONE" }
  | { outcome: "INVALID_USERNAME" }
  | { outcome: "SUCCEEDED" }

Delta/Novo estado: objeto contendo os valores derivados (ex.: passwordHash, normalizedEmail, objetos VO prontos). Pode ser:

O objeto completo que representa a entidade pronta para criar, ou
Apenas as mudanças (delta) para aplicar ao estado atual.

Ambas formas são puras.

A partir disso, a Factory, uma função pura, recebe os dados validados/derivados (delta) e monta a entidade/VO final de forma imutável.

O Orquestrador entre Domínio e Infraestrutura

Após entendermos que o Deriver decide as regras de negócio puras, precisamos de uma camada que orquestre o caso de uso. É aqui que entra o Handler (às vezes também chamado de Use Case ou Shell).

O Handler não contém regras de negócio profundas: ele coordena o fluxo de uma operação. Ele recebe um DTO já validado, chama o Deriver para obter um Outcome e, dependendo desse resultado, decide o próximo passo.

Se o Deriver retornar uma falha, o Handler devolve essa falha diretamente para o controller. Se retornar um “SUCCEEDED” com um delta/novo estado, então o Handler chama a Factory para montar a entidade final e delega ao repositório o trabalho de persistência.

Todo esse conhecimento adquirido se traduziu neste projeto simples, onde busquei seguir um modelo de arquitetura Package by Feature, fazendo algumas adaptações para o cenário no qual estou mais acostumado. Para entender mais da arquitetura, deixo o ótimo artigo do Waldemar Neto que serve como guia e que eu utilizei como base para desenvolver meu projeto.

Aos poucos vou me aprofundando em TypeScript e programação funcional, mas esse primeiro passo foi bem divertido e já me mostra ótimas possibilidades para o futuro.

Referências:

Arquiteturas Emergentes Que Você Precisa Conhecer: Package by Feature, Vertical Slice e Modular
Domain-driven design in functional programming
Domain-Driven Design (DDD) com Programação Funcional?!?!
Functional Domain Driven Design: Simplified
Domain Driven Design implemented by functional programming

WSL2 e Docker sem Docker Desktop: configurando NAT e acesso localhost manualmente

Igor Oliveira — Wed, 05 Nov 2025 01:16:32 +0000

Há um tempo eu venho tentando contruir um SaaS como forma de praticar meus estudos. Durante várias ideias e tentativas, eu me deparei com um problema relacionado ao docker: por algum motivo, o Docker Desktop não queria funcionar com Windows.

O que foi estranho e pareceu ser um problema simples de resolver, acabou se tornando uma dor de cabeça tremenda e me levou a buscar novas alternativas. O uso do WSL2 se mostrou como caminho, não só para resolver um problema, mas como um tópico de estudo para além da programação.

O WSL2 não é uma simples compatibilidade de comandos UNIX dentro do Windows. Ele roda um kernel Linux completo em uma máquina virtual leve baseada em Hyper-V. Quando o Docker Desktop é configurado para usar o WSL2 como backend, todos os containers são criados dentro desse kernel Linux, e não diretamente no Windows.

A comunicação entre o Windows e o ambiente Linux do WSL2 é feita via uma interface virtual criada pelo Windows: vEthernet (WSL). Ela é, na verdade, um Switch Virtual criado automaticamente pela plataforma de virtualização do Windows (chamada Virtual Machine Platform, um componente do Hyper-V) quando o WSL2 é iniciado pela primeira vez. Essa interface atua como única ponte de rede entre dois ambientes isolados:

O sistema operacional Windows (Host).
O kernel Linux/VM do WSL2 (Guest).

O principal mecanismo que ela gerencia é o NAT (Network Address Translation). O Linux (WSL2 VM) recebe um IP privado (por exemplo, 172.27.x.x ou 192.168.x.x) que muda a cada reinicialização do Windows. Esse IP funciona como Gateway Padrão e Servidor DNS dentro do ambiente Linux, permitindo que o tráfego de saída seja traduzido para a rede do host. No lado do Windows, a interface vEthernet (WSL) recebe o primeiro endereço desse bloco privado (por exemplo, 172.27.x.1) e atua como o roteador/NAT responsável por gerenciar todo o tráfego entre o Windows e a VM Linux.

Teoricamente, o Docker Desktop deveria configurar o proxy automático de portas por meio da interface vEthernet (WSL), permitindo que minha aplicação no Windows acessasse o container através do endereço localhost:1433. No entanto, como optei por rodar o Docker Engine nativo diretamente na minha distribuição WSL2, eu não contava com o serviço de encaminhamento automático de portas que o Docker Desktop injeta no host Windows.

Assim, minha aplicação .NET, executando no Windows, tentava se conectar a localhost:1433. Como não havia o serviço de port forwarding do Docker Desktop, o Windows não sabia que o tráfego dessa porta deveria ser redirecionado para o endereço IP dinâmico da VM WSL2 (geralmente algo como 172.x.x.x). Por isso, a conexão falhava.

Uma alternativa para contornar esse problema foi criar uma rede personalizada no Docker e expor a porta do container do SQL Server para o host Windows. Essa configuração permitiu que o tráfego de localhost:1433 fosse corretamente roteado até o container, mesmo sem o proxy de portas do Docker Desktop.

O primeiro passo foi criar uma rede bridge isolada com suporte a DNS interno:

docker network create mynetwork

Essa rede cria uma bridge virtual (por exemplo, br-2c7e9a5d7b45) com uma sub-rede dedicada (172.18.0.0/16) e um gateway interno (172.18.0.1).
Containers conectados a ela podem se comunicar diretamente por nome, sem precisar de IP fixo.

Em seguida, subi o container do SQL Server conectado a essa rede e expus a porta 1433:

docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=YourStrong!Passw0rd" \
  --name sqlserver \
  --network mynetwork \
  -p 1433:1433 \
  -d mcr.microsoft.com/mssql/server:2022-latest

O parâmetro -p 1433:1433 faz o mapeamento de porta entre o host (Windows) e o container, permitindo que a aplicação fora do WSL2 acesse o serviço pelo localhost:1433.

O --network mynetwork garante que, se eu decidir rodar outros containers (por exemplo, uma API .NET) dentro do WSL2, eles poderão se conectar via DNS interno — usando apenas sqlserver como host.

Para confirmar a conectividade, testei o acesso diretamente do Windows:

Test-NetConnection localhost -Port 1433

E também validei de dentro da aplicação .NET, configurando a connection string da seguinte forma:

"Server=localhost,1433;Database=MyAppDb;User Id=sa;Password=YourStrong!Passw0rd;TrustServerCertificate=True;"

Após isso, a aplicação passou a se conectar normalmente ao SQL Server rodando dentro do container, mesmo com o Docker Engine isolado dentro da VM WSL2.

Mas, por que essa solução funciona?

Ao expor a porta (-p 1433:1433), o Docker criou uma regra de DNAT (Destination NAT) na tabela iptables do Linux interno do WSL2. Essa regra instrui o kernel a redirecionar todo o tráfego recebido na porta 1433 do host (interface eth0) para o IP interno do container SQL Server.

Quando o Windows acessa localhost:1433, o pacote é enviado à interface vEthernet (WSL) → traduzido pelo NAT → entregue à bridge br-xxxxx → e finalmente roteado ao container. Com isso, o comportamento esperado do Docker Desktop foi restaurado manualmente, mas de forma controlada e previsível.

Desvendando o Three-Way Handshake - Parte 1: A Engrenagem Invisível da Comunicação TCP

Igor Oliveira — Thu, 02 May 2024 23:33:49 +0000

A comunicação desempenha um papel crucial no funcionamento da Internet, com destaque para o uso do TCP (Transmission Control Protocol). Localizado na camada de transporte, o TCP é essencial para a transmissão de dados pela rede, assegurando a comunicação e a transferência de informações entre sistemas de forma confiável e segura.

Na estrutura Cliente-Servidor, o TCP é fundamental para facilitar a comunicação e a troca de informações. Mas como exatamente essa conexão é estabelecida? Embora saibamos que o three-way handshake é o mecanismo utilizado para essa comunicação, vamos explorar mais detalhes com base nos sistemas operacionais Unix.

Criação e Configuração do Socket:

Durante o processo de conexão, o servidor web delega a responsabilidade das conexões TCP para o kernel do sistema operacional, garantindo eficiência, confiabilidade e segurança na comunicação em rede.

Quando um processo de aplicação solicita a criação de um socket de comunicação, o sistema operacional aloca recursos para esse novo socket, como memória, e cria estruturas de dados necessárias para representar o socket no nível do kernel. Em seguida, um “File Descriptor” é atribuído a esse socket.

Esse File Descriptor é disponibilizado para a aplicação, que configura o socket para receber novas conexões, geralmente utilizando primeiro a chamada bind(), indicando ao sistema operacional o endereço e a porta para escutar novas conexões.

Em seguida, a aplicação coloca o socket no estado de 'Listen' utilizando a chamada de sistema listen(), informando ao sistema operacional que o socket está pronto para aceitar novas conexões de entrada.

Estabelecendo conexão:

Quando o cliente deseja se conectar a um servidor, ele envia um segmento SYN (synchronize) para o servidor de destino. O kernel do sistema operacional, ao receber o segmento SYN, verifica se há um processo esperando conexão pela porta especificada no segmento. Se houver, o segmento SYN é aceito, e o kernel aloca recursos para a nova conexão, colocando as informações na SYN queue, aguardando confirmação.

Após esse processo, o kernel envia um SYN/ACK para o cliente, reconhecendo o segmento recebido e enviando outro segmento SYN para que o cliente também o reconheça. Em seguida, o cliente envia um ACK, confirmando o recebimento.

O recebimento desse ACK pelo kernel do servidor conclui o three-way handshake. O kernel move as informações para a Accept Queue, onde as conexões estabelecidas, mas não aceitas pela aplicação, são mantidas.

Quando a conexão está no backlog, a aplicação pode utilizar a chamada de sistema accept() para aceitar a conexão específica e iniciar a troca de informações com o cliente, utilizando o file descriptor associado para interagir com o cliente por meio das chamadas read() e write().

Em suma, o estabelecimento adequado das conexões TCP é crucial para a comunicação eficiente entre clientes e servidores na Internet. Através do meticuloso processo de three-way handshake e do cuidadoso gerenciamento pelo kernel do sistema operacional, as informações podem ser trocadas de forma confiável e segura. Por trás da aparente simplicidade de clicar em um link ou enviar uma mensagem, há uma intrincada dança entre o hardware, o software e os protocolos de rede.

Entendendo HTTP - Parte 1

Igor Oliveira — Fri, 12 Jan 2024 21:37:26 +0000

Quando abordamos o desenvolvimento de aplicações para o backend, é crucial ter um entendimento sólido sobre o HTTP ao iniciar um projeto. Como o protocolo de transferência de dados mais popular na internet, o Hypertext Transfer Protocol desempenha um papel integral em nossa experiência online há mais de duas décadas, sendo a base para as conexões entre cliente e servidor.

O HTTP opera na camada sete do modelo OSI e utiliza o TCP para estabelecer a conexão entre cliente e servidor. Na virada do século, à medida que a internet ganhava popularidade, a experiência do usuário era notavelmente diferente da que conhecemos hoje. A versão 1.0 do HTTP foi introduzida em 1996 e, naquela época, era o protocolo dominante para a transferência de informações entre cliente e servidor. No entanto, começou a manifestar algumas limitações.

O HTTP/1.0 permitia apenas o processamento de uma única solicitação por conexão. Isso significava que, para cada requisição do cliente ao servidor - como imagens, scripts ou folhas de estilo - uma nova conexão precisava ser aberta. Esse processo resultava em um desempenho lento da página, aumentando a latência e tornando o carregamento do site moroso.

Diante dos desafios impostos pelo HTTP/1.0, surgiu a necessidade de um protocolo mais eficiente. Em 1999, foi oficialmente introduzido o HTTP/1.1, destinado a superar as limitações de seu antecessor. A mudança mais impactante foi a introdução da persistência de conexão, conhecida como "Keep Alive", que permitia várias solicitações e respostas serem transmitidas pela mesma conexão. Isso eliminou a necessidade de abrir uma nova conexão para cada recurso, reduzindo drasticamente a latência e aprimorando o desempenho no carregamento das páginas web.

Além disso, a versão 1.1 também introduziu a pipeline de requisições, o que permitiu o envio de várias solicitações antes de receber as respostas, otimizando ainda mais a comunicação entre clientes e servidores.

Com a chegada da nova versão do protocolo, a internet passou por uma revolução. As páginas web tornaram-se mais rápidas, e a experiência do usuário melhorou significativamente. A eficiência na troca de dados contribuiu para o crescimento exponencial de serviços online, impulsionando o comércio eletrônico, redes sociais e muito mais.

Em resumo, a transição do HTTP/1.0 para o HTTP/1.1 marcou um ponto de virada crucial na evolução da internet. As inovações introduzidas não apenas resolveram os problemas de latência e ineficiência, mas também pavimentaram o caminho para o desenvolvimento contínuo da World Wide Web.

Entendendo Herança e Composição

Igor Oliveira — Mon, 27 Feb 2023 20:15:33 +0000

A programação orientada a objetos é uma parte importante e muitas vezes necessária na formação de um programador. Um dos conceitos fundamentais dessa abordagem é a herança, que nos permite reutilizar código em nossos projetos, dentre outras coisas. No entanto, além da herança, existe outro conceito básico que pode ajudar no desenvolvimento de aplicações, a composição. Mas qual a diferença entre herança e composição? A diferença está na forma como uma classe interage com outras classes dentro do código.

A herança é um mecanismo em POO onde uma classe herda propriedades e métodos e outra classe permitindo a criação de hierarquia de classes, onde uma classe filho (subclasse) é derivada de uma classe mais geral, ou classe pai (Superclasse):

No exemplo acima, a classe 'Gato' herda todos os atributos e métodos da classe 'Animal' além de possuir seu próprio atributo e método chamado "raça".

Pro outro lado, a composição é um mecanismo em POO que cria uma relação do tipo 'tem-um' com outra classe:

No exemplo acima, temos uma classe chamada 'Motor' e logo em seguida uma classe chamada 'Carro'. O que é importante notar aqui é que a classe 'Carro' não estende a classe 'Motor', mas sim cria uma instância da mesma para ser um de seus membros. Assim, a classe 'Carro' terá seus próprios métodos e também poderá acessar os métodos da classe 'Motor' por meio dessa instância criada.

Entre os exemplos do uso de herança, podemos citar:

A reutilização de código através de uma classe já existente.
A criação de uma classe genérica que pode ser usada como base para outras classes.
Definir uma hierarquia de classes dentro do código.

Já os exemplos de uso da composição, podemos citar:

A criação de objetos complexos através de objetos mais simples.
A possibilidade de combinar funcionalidades de classes diferentes em um único objeto.
Permitir a reutilização de código sem a necessidade de criar hierarquias de classes.

A principal diferença entre herança e composição é que a herança é uma relação do tipo "é-um", enquanto a composição é uma relação do tipo "tem-um". Em outras palavras, na herança, uma classe é um tipo de outra classe (ex: Gato é um tipo de Animal), enquanto na composição, uma classe possui objetos de outras classes (ex: Carro tem um Motor).

Estrutura de Dados parte 2: Algoritmos de busca.

Igor Oliveira — Fri, 17 Feb 2023 19:54:15 +0000

Um dos conceitos mais importantes dentro da ciência da computação atualmente se refere à busca de dados dentro de uma estrutura. Com o número de informações disponíveis na rede, a busca eficiente por um elemento se tornou parte importante do trabalho de um desenvolvedor de software. Diante disso, surgem dois principais métodos de busca: o algorítimo de busca sequencial e o algoritmo de busca binária.

Busca Sequencial

Como o próprio nome já sugere, o algorítimo de busca sequencial — podendo ser chamado também de busca linear — é uma estrutura de dados que percorre cada elemento de um vetor até encontrar o valor desejado. O algorítimo sequencial possui complexidade O(n), ou seja: apesar de funcionar para vetores com poucos elementos, o mesmo pode se tornar custoso na medida em que o número de elementos dentro do vetor cresce, tendo seu pior caso o enésimo elemento de um determinado array: A = {0... N-1}.

Veja o exemplo de um algoritmo de busca linear abaixo:

É importante notar no código acima que, apesar do vetor estar desorganizado, isso não altera o retorno da função. Isso ocorre porque o algoritmo de busca sequencial independe do vetor estar ordenado para funcionar!

Busca Binária

Se a busca sequencial pode se tornar custosa a medida em que o número de elementos dentro de um vetor cresce, o algoritmo de busca binária surge como uma maneira mais eficiente de encontrar um elemento dentro de um array.

Tendo seu tempo de execução O(log n), o algoritmo funciona verificando o item que está no meio do vetor, e caso não seja o valor correto, podemos eliminar uma das metades do array. A partir disso, ele divide repetidamente a metade que possivelmente contem o item, até que a lista seja reduzida somente em um elemento.

Dividindo o número de elementos presentes no vetor a cada execução, o algoritmo binário diminui o número de interações necessárias para encontrar o elemento desejado, tornando-o assim mais eficiente que o algoritmo linear.

Abaixo uma comparação gráfica entre os dois:

Por levar em consideração os maiores e menores números de um vetor para fazer a divisão, o algorítimo de busca binária obrigatoriamente precisa de um array ordenado para funcionar. Por conta disso, pode ser necessária a utilização de um algoritmo de ordenação antes de utilizá-lo.

Estrutura de dados parte 1: Vetores e Matrizes.

Igor Oliveira — Tue, 06 Sep 2022 20:41:39 +0000

Essa serie de textos faz parte dos meus estudos da faculdade referentes à matéria de pesquisa, orientação e técnicas de armazenamento de dados. Uma boa maneira de por em prática o que se foi aprendido é compartilhar esse conhecimento com mais pessoas.

Esse primeiro texto abordará as estruturas de dados simples como vetores e matrizes.

Quando falamos de computação, principalmente sobre armazenamento, basicamente estamos falando de dois tipos: o armazenamento interno e o armazenamento externo. De maneira bem simples: Armazenamento externo pode se caracterizar como o tipo de armazenamento que diz respeito aos dados que são guardados em aplicações ou dispositivos fora da aplicação, como um banco de dados ou HD. Já o armazenamento interno diz respeito aos dados que são armazenados dentro da própria aplicação, podendo ser acessados através de instruções diretas do programa e de acordo com a lógica necessária. O armazenamento interno tem como estrutura elementar uma variável.

A variável é um espaço em memória responsável por alocar uma informação dentro da aplicação, seja ela um inteiro, uma string ou um booleano, sendo possível recuperá-la através de seu nome identificador. Por ser capaz de guardar somente uma informação dentro de si, a variável acaba sendo uma estrutura inviável para se trabalhar com uma grande quantidade da dados. Por exemplo: imagine que você tenha seis pessoas e precise armazenar o nome delas, seria inviável em uma aplicação criar seis variáveis para armazenar cada um desses seis nomes, além de dar muito mais trabalho para tratar esses dados futuramente.

Por conta disso nós utilizamos vetores. Vetores são uma forma eficiente e indexável de armazenamento de dados em uma aplicação, permitindo o armazenamento de mais de um dado em uma mesma estrutura, podendo assim economizar código atribuindo à uma única variável diversos dados.

Cada um dos nomes armazenados dentro desse vetor possuem um respectivo índice de identificação que começa do 0 e vai até N, sendo N o número total de elementos presentes no vetor.

Normalmente vetores apenas armazenam dados do mesmo tipo, ou seja, um vetor de inteiros só armazena números inteiros. Entretanto, no JavaScript é possível armazenar dados de diferentes tipos em um mesmo vetor:

Além do vetor, nós também trabalhamos com as matrizes. Uma matriz é uma estrutura computacional bidimensional, capaz de armazenar dados de maneira em que os mesmos sejam guardados como uma tabela. Assim como nos vetores o acesso aos elementos presentes nas matrizes se da através de índices, mas nesse caso, utilizando as coordenadas da linha e coluna para indicar exatamente onde esse elemento se encontra.

Dentro da memória, os vetores são armazenados de maneira similar à uma variável, tendo de diferente apenas que sua referência indexada aponta para mais de um espaço em memória.