ola, ja fui aluno e tentarei ajudar ... Quando ouço em “separar o banco de dados da aplicação”, em uma abordagem arquitetural então entendo que vamos dividir responsabilidades entre a aplicação e o banco de dados.
Separação de Responsabilidades, como vc mesmo citou em uma aplicação monolítica, muitas vezes o código da aplicação e a lógica de acesso ao banco de dados estão ligados. Isso significa que a aplicação é responsável por gerenciar conexões, consultas SQL e manipulação dos dados.
Mas na separação física, quando dizemos “separar o banco de dados da aplicação”, estamos considerando a possibilidade de hospedar o banco de dados em um servidor separado, independentemente da tecnologia de banco de dados utilizada (MySQL, DynamoDB, MongoDB etc.).
Isso significa que o banco de dados não está mais “embutido” na aplicação. Ele tem sua própria infraestrutura, como servidores, armazenamento e recursos de processamento.
Além da separação física, também é possível separar a lógica de acesso ao banco de dados da aplicação, significa criar uma camada intermediária (como APIs REST ou GraphQL) que gerencia as consultas e transações com o banco de dados. A aplicação interage com essa camada, e ela, por sua vez, lida com as operações no banco de dados.
Acredito que o instrutor estava se referindo tanto à separação física quanto à separação da lógica de acesso ao banco de dados. Ambas são boas práticas para criar sistemas mais escaláveis, flexíveis e fáceis de manter
Bons estudos aí!!!
