[DÚVIDA] Padrão de projeto

Que massa parabens 🎉

Antes de tudo vou te Recomedar a usar o NOTION para você se organizar...
Segundo vou recomendar que faça por partes e a
Melhor tecnologia que existe e aquela que a gente domina...
então fica aqui os pilares,

Caso necessite de ajuda fico a disposição, no meu perfil tem meu linkedin. 🤝

Se realmente estiverem te pedindo para fazer o sistema de folha, pesquise alguma solução pronta e apresente pra eles e mostre que via integração o sistema que você vai fazer, poderá compor a solução. Como por exemplo, você pode fazer uma página de trabalhe conosco, em que a pessoa cadastra os dados dela, e seu sistema abastece o sistema de RH com o candidato, depois quando for contratado seu sistema poderá abastecer a tela de "meu perfil" do seu sistema. onde o funcionário poderá por exemplo atualizar o endereço dele, e isso voltar para o sistema de folha (com validações ou etapas de aprovações pelo DP).

Como uma forma de fazer isso mais rapidamente, eu sugiro você pesquisar Infyom https://github.com/InfyOmLabs/adminlte-generator/tree/8.0
Assim como você, meu conhecimento inicial era mais em banco de dados, e o infyom me ajudou muito, porque ele faz o scaffold de tabelas do banco no template AdminLte https://adminlte.io/themes/v3/ (na versão 2 até a última vez que usei)

Como isso funciona? Você faz o download do boilerplate no primeiro link. copia o .env.example para .env e coloca as credenciais do banco que vai criar para o projeto. Roda as migrations que vêm no boilerplate (elas criam 4 tabelas, dentre elas a tabela de usuários). Então você roda os comandos iniciais para rodar um projeto Laravel. (php artisan key:generate,composer install...) e você já tem um sistema com login pronto.

A melhor parte vem agora, digamos que você tenha uma tabela "funcionarios". você executa:
php artisan infyom:scaffold Funcionario --fromTable --tableName=funcionarios
(obs: toda tabela tem que ter as colunas created_at,updated_at,deleted_at. Se o plural não for comum como Secao, coloque --plural=secoes, senão ele gera secaos)

Automaticamente vai ser criado a model Funcionario, o controller, as rotas em web.php e api.php, uma entrada no menu lateral para acessar os funcionários, uma tela com a lista de funcionários e o crud completo, para criar, editar, excluir, visualizar.

Claro que só esse comando não vai te entregar o sistema pronto, você vai ter que entrar nas views e colocar acento nos labels por exemplo. Mas vai te salvar muuuito tempo nas tarefas repetitivas e chatas iniciais que esse tipo de sistema demanda.

Você ainda pode entrar config\infyom\laravel_generator.php, habilitar o datatables (precisa instalar ele via composer) e com isso, quando você fizer o scaffold, a tela de listagem já vai vir também com um datatables, permitindo ordernar por cada coluna, exportar pro excel, pesquisar, paginar...

Acho que vale pelo menos baixar e fazer esse teste pra você poder avaliar.

Estude os padrões e outras coisas da computação. quando tiver um problema que ele se encaixa você o usa. Precisa de experiência para tomar uma boa decisão, não é receita de bolo. Quase 100% das pessoas que pergutam sobre o uso de padrões de projeto, querem fazer isso porque ouviram falar que é bom, e não é assim que funciona, o desastre virá.

Na minha visão tanto Python quanto PHP são inadequadas, embora dê para fazer, porque será web e folha não deveria ser.

De qualquer forma eu já trabalahei em empresa especializada nisso, também onde folha era um dos produtos e em empresas que usavam folha, além de conhecer muitos casos que não trabalhei. Nunca vi uma só empresa que fez sua própria folha de pagto, é um dos softwwares mais difíceies de manter e que menos é importante para uma empresa ter algo próprio. O que vão gastar nos primeiros meses para fazer isso será mais do que pagarão de mensalidae de algo pronto na vida inteira da empresa, e sempre terá um software bem pior do que já existe no mercado.

Ou seja, parece que todos os erros possíveis serão feitos nesse projeto. Eu repensaria muita coisa. Eu até falaria para contratar uma consultoria, mas agora evito porque quase semrpe até isso sairá errado. Lamento. E eu sei que provavelmente este conselho não srá seguido.

Ajudei? Era o meu desejo.

---

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

Mas dito isso, gostaria de fazer da melhor maneira possível, para que seja um projeto bem estruturado e de valor. E minha primeira dúvida é sobre o padrão do projeto, pois ainda não fiz uso de nenhum padrão (MVC, MVP, ETC) em desenvolvimento.

Qual seria a melhor abordagem para um projeto dessa natureza?
óbviamente teria que ser modular, pois creio eu que ficaria melhor para dar manutencão e adicionar novas aplicações se necessário e também dar manutenção (assim imagino, mas se existirem outras formas sou todo ouvidos).

E a outra dúvida, sobre a tecnologia a ser utilizada. Eu estou ponderando entre python e PHP, que são as tecnologias que mais tenho familiaridade (porém ainda não fiz uso de frameworks). Vi que python tem muitas bibliotecas que podem me ser úteis, mas também já desenvolvi algumas aplicações web com PHP. A modelagem do banco de dados estou indo bem, trabalho mais com banco de dados e analise de dados do que com desenvolvimento.

Para todas essas perguntas a resposta eh a mesma. A que você estiver mais confortável.

E também sobre como documentar/versionar o projeto de forma adequada se necessário

Qualquer servidor git se quiser pode começar com o um projeto privado do GitHub

Agora minha sugestão de verdade é tentar ver se já existe algum produto que atende às necessidades da sua empresa. Assim você entrega algo redondo mais rapido e aprende a fazer manutenção neste produto.

Você está diante de um grande desafio com este projeto. Portanto, é crucial abordá-lo com cautela, mantenha as coisas simples. Não adicione complexidade desnecessária. E se apoie no que você conhece melhor.

Como seu conhecimento é mais voltado para bancos de dados do que para desenvolvimento, é aconselhável abraçar profundamente a programação de banco de dados e definir todas as suas regras de negócio em SQL procedural. Em vez dos padrões comumente sugeridos, eu recomendaria adotar o padrão Data Transfer Object (DTO) e construir uma interface simples para sql que englobem consultas complexas.

Isso se justifica porque padrões como MVC, MVP, MVVM (entre tantos outros) são decisões de arquitetura de software que se baseiam essencialmente na separação entre a representação da informação (modelo) e a apresentação para o usuário (visão), o modelo é a essência da sua aplicação, e muitos desenvolvedores web não compreendem plenamente essa importância. Ao focar na construção de um modelo de dados robusto e na utilização, você cria uma base sólida para sua aplicação. Isso permite que você mantenha a flexibilidade na camadas superiores e escolha as ferramentas que melhor complementam suas habilidade e atendam suas necessidades.

Lembre-se de que muitos dos frameworks web são implementações de padrões como MVC, MVP, MVVM, oferecendo um fluxo de trabalho coeso para conectar visualizações a modelos, com um ORM sendo parte de quase todos eles. Contudo, como você já criou seus modelos sem a necessidade desses frameworks, é preferível continuar evitando-os. Um microframework pode ser útil, especialmente para o roteamento, mas talvez seja mais benéfico utilizar recursos nativos do próprio Apache ou Nginx.

Sua visualização deve ser composta por templates PHP simples, com JavaScript minimalista para buscar conteúdo dinamicamente e evitar redirecionamentos. Evite transferir JSON e, em vez disso, opte por HTML gerado diretamente no servidor. Ao adotar uma abordagem semelhante a uma aplicação SPA, você simplifica a lógica do backend e mantém o estado do cliente no próprio cliente. Ao mesmo tempo, ao usar HTML diretamente, você evita complicar seu frontend com frameworks próprios e JavaScript complexo para lidar com o DOM. Essa abordagem representa o melhor dos dois mundos e deveria ser óbvia para todos que estudaram o padrão cliente/servidor, outro padrão clássico que muitos desenvolvedores web negligenciam.

Outra padrão de projeto muito vezes renegado é gerar páginas estáticas sempre que o modelo mudar, em vez de depender de renderização baseada em requisições. Isso não é apenas mais eficiente, mas também pode simplificar significativamente sua arquitetura.

Mantenha sua aplicação o mais simples possível. Evite microserviços, mas abrace módulos e crie várias miniaplicações que funcionem bem juntas, em vez de uma única aplicação gigante. Considere usar soluções de terceiros, como Keycloak, para gerenciamento de autenticação e autorização SSO. Isso ajudará a manter sua aplicação simples e direta.

Em resumo, na sua posição, é isso que eu faria, depois de décadas de experiência com desenvolvimento web. Essas não são apenas algumas ideias aleatórias, mas sim uma abordagem baseada em práticas estabelecidas, que ao mesmo tempo incorporam as últimas tendências e tentam manter a simplicidade.

Estamos falando de uma abordagem baseada no MVC, com DTOs fazendo a ponte entre o Modelo e Controle e Modelo e View, que abraça os principais padrões da web - SSG, SSR, e SPA:

• Modelo (SSG): Reconstrução automática do site a cada mudança no modelo de dados, utilizando técnicas como pg_notify em triggers do banco de dados. Esta abordagem permite que o site seja atualizado de forma eficiente sempre que os dados são modificados.

• Visualização (SSR): Utilização de PHP para reconstruir o HTML do site a partir das mudanças do modelo. Aqui, você pode (e deve) integrar scripts Python, se necessário, para complementar a lógica de negócios. Os Data Transfer Objects (DTOs) entram nesta fase, proporcionando uma ponte eficaz entre o modelo e a camada de visualização.

• Controle (SPA): Para a navegação e interatividade, adota-se uma abordagem SPA-like, utilizando JavaScript e uma configuração adequada do Nginx. Esta configuração é responsável por gerenciar a interação do usuário e servir o conteúdo gerado na etapa de visualização. Para requisições post (put, etc), novamente DTOs funcionam como uma ponte entre o controle e o modelo.

No entanto, é importante ser cauteloso, pois este caminho pode não ser o melhor para você. Uma abordagem muito flexível como esta permite uma grande margem para erros – e eu sei por que eu mesmo já cometi vários. Usar um framework que limita essa flexibilidade pode ser benéfico, pois evita certos erros. Portanto, talvez você esteja melhor servido usando algo como o Laravel ou Django ao invés de seguir qualquer uma das sugestões que eu dei aqui. Ha! Mas, independente das ferramentas e abordagens que você escolher, espero que pelo menos tenha te convencido a passar longe dos ORMs.

Um abraço e bons estudos!