Por que eu devo ler este artigo:O desenvolvimento de aplicações Multi-Tenant é uma realidade há muito tempo, embora muitas pessoas não saibam disso.

O conceito de muitos usuários de uma mesma aplicação está presente desde os primórdios da programação, mas o conceito como o conhecemos hoje só surgiu com o SaaS (Software as a Service).

Este artigo é útil, pois com ele vamos aprender as possíveis arquiteturas das aplicações Multi-Tenant utilizando o ASP.NET MVC. Além disso, veremos como os múltiplos usuários vão interagir com a aplicação, cada um dentro de seu espaço e com suas regras de negócios, sem invasões.

Quando estamos desenvolvendo aplicações, normalmente temos um público-alvo em mente, um usuário (ou uma série deles) que, teoricamente, irá utilizar essa aplicação.

Essa é uma premissa básica do desenvolvimento de software. Entretanto, quando criamos aplicações que serão utilizadas por múltiplos usuários, também precisamos lidar com as necessidades individuais de cada um deles.

Hoje em dia, não existe mais aquele negócio de que o usuário precisa se adaptar à solução criada: o contrário é muito mais comum – as empresas precisam adaptar suas soluções para criar experiências cada vez melhores para os usuários.

Na prática, isso significa que estaremos lidando com várias necessidades similares em uma mesma aplicação.

Mas vale a ressalva: é preciso um certo cuidado com essas “similaridades” – não vamos criar uma aplicação Multi-Tenant para um usuário do agronegócio e uma loja de sapatos – nesse caso, há muito mais diferenças do que similaridades entre as regras de negócios.

A lógica é relativamente simples de ser entendida, embora mais complexa de ser implementada: regras de negócios similares fazem valer a criação de uma aplicação Multi-Tenant, como, por exemplo, uma aplicação para agricultores e agropecuaristas, onde cada um deles possui necessidades específicas, como uma ideia similar por trás de tudo.

O objetivo deste artigo é que o leitor, ao final, tenha uma ideia básica de como aplicar alguns conceitos dessa arquitetura e possa lidar com as similaridades e as diferenças entre as necessidades de cada usuário de forma melhor.

Traremos as possíveis arquiteturas de dados para esse tipo de aplicação, indicando algumas possibilidades para o leitor, e faremos um exemplo baseado em uma delas: um schema básico da base de dados seguido de extensões específicas para dois tipos de usuários, uma das abordagens mais comuns para o desenvolvimento Multi-Tenant.

Software as a Service (SaaS) vs Multi-Tenant

O conceito de Software as a Service (SaaS) costuma andar lado a lado com as aplicações Multi-Tenant, como as conhecemos hoje.

Isso não significa que toda aplicação Multi-Tenant será um exemplo de SaaS, mas é o mais comum a ser feito. O que acontece é que as aplicações Multi-Tenant, pela forma como são estruturadas, permitem a adição de usuários (tenants) com certa facilidade, o que se encaixa na forma de utilização do SaaS.

Mas afinal, o o que é o Software as a Service? Como o nome sugere, trata-se de um “Software como Serviço” (em uma tradução literal). Em outras palavras, temos um produto de software que é desenvolvido e vendido como se fosse um serviço, de diversas formas.

Atualmente, vemos exemplos de SaaS sendo contratados mensalmente, diariamente, por utilização, ou ainda outras formas de utilização, dependendo do negócio a que o software se propõe.

Em uma definição mais completa, Software as a Service é um modelo de negócios para software. Um modelo de licenciamento e utilização de software que vem ganhando cada vez mais espaço, especialmente porque o mundo, globalizado como está, praticamente não suporta softwares de prateleiras, muito comuns no começo do século.

Os usuários entenderam os benefícios de gastar menos, inicialmente, e “contratar” um software, bem como as empresas entenderam que receber periodicamente dos usuários é mais interessante, a longo prazo, do que receber pelas vendas do software apenas uma vez.

A grande sacada do SaaS é que ele não está restrito ao que estava proposto pelo software, ou seja, não está limitado a uma solução genérica que se encaixa em vários tipos de problemas. A ideia é que nós, desenvolvedores, tenhamos a possibilidade de criar soluções específicas para cada usuário, partindo de uma base comum a vários deles.

E isso acaba sendo melhor para todos: desenvolvedores, que trabalham mais (e consequentemente recebem mais) e usuários, que recebem um produto adaptado à suas necess ...

Fim do trecho gratuito • continue abaixo
CONTEÚDO EXCLUSIVO

Desbloqueie toda a DevMedia

  • +2000 artigos e vídeos
  • +40 trilhas sobre Front-end, Back-end, IA e muito mais
  • +5000 exercícios práticos
  • Mentorias ao vivo individuais
até 50% OFF
A partir de
R$ 69 /mês
Assinar agora