Projeto para finalizar última entrega - Pós-graduação FIAP
link para leitura: Doc Domain Driven Design
A ideia por de trás deste conceito é a de receber um vídeo ou mais, realizar o processamento dos mesmos, tirar prints de cada frame sem que nenhum se perca,
persistir os prints em base dados. Como arquiteto, a primeira questão a se pensar é a de "custos". Quão será custoso para realizar tal tarefa de processamento de tais arquivos,
mante-los em base dedados e consumi-los. A princípio, para as tarefas mais simples, pensando a baixo nível, seria uma aplicação com persistência poliglota,
será necessário um banco de dados que trabalhe com chave e valor como o MongoDB 
para persistir nossos prints e um outro banco como PostgreSql
para persistir informações referente ao tipo de arquivo enviado.
Após criação dos itens para persistir nossos arquivos e informações, partimos para a parte de processamento, preciso que cada video encaminhado para o processamento não interrompido, vejo uma alternativa como um serviço reativo talvez, mensageria.
A arquitetura a ser adotada para este projeto sera clean architecture.
A arquitetura limpa coopera com o business, organização, design e manutenibilidade, sempre respeitando os adapters e gateways. Na medida em que a construção e implementação das features, venho analisando melhor a arquitetura e me pergunto se não seria melhor para esse cenário a arquiteura event-drive, como prentendo criar um serviço assíncrono, irei utilizar apache kafka para enfileirar meus objetos para que eu possa ter mais organização de fluxo de request e esta arquitetura coopera bastante com esse cenário, possa ser que eu mude ao final do projeto.
Infelizmente, não pude adotar a arquitetura voltada a eventos event-driven. Esta arquitetura lida diretamente com filas, processos assíncronos, e para este cenário,
não pude utilza-la, a um certo limite de bytes para usar filas e o kafka não iria suportar o tamanho da stream. Então parti para serviços não blockantes.
Brinquei bastante com spring webflux 
Ao final, fui para o simples, subi o tento do Java na aplicação, sai do Java17 e fui para Java21, assim eu posso trabalhar com threads virtuais, nos meus testes, as requisições foram bem sucedidas, porém, minha rest-api atua blockante, é um trade-off que minha arquitetura adotada me atribuiu, o famoso Over-engineering.
Tudo isso é muito interessante, houve momentos em que parti para o que realmente interessa, yagne, mas após todo esse processo de refactoring, percebi que é necessário se pensar com clareza na adoção das coisas simples, na medida em que você constroi a aplicação, você precisa analisar se está pensando em atender o problema ou usar tal arquitetura ou padrão de projeto. Encontri diversas falhas durante o processo de desenvolvimento, realizaei diversas alterações, depuração, debugs, logs e outros meios mais de me esgotar ao ponto de volta ao início do problema e partir para a adoção do simples. Este projeto cooperou bo quesito visão arquitetural.
Cobertura baixa de testes, mas existe teste.
A imagem da aplicação está disponibilizada no DockerHub ou baixe a imagem agora mesmo
docker push migprogrammer/process-videos:tagname
Observações e considerações: Ao abaixar a imagem, será necessário ter o banco NoSql MongoDb instalado, também, deixe os seus vídeos nao seguinte diretório 'C:\videos'.
Usei o Dynatrace para ver como a aplicação lidá com o processamento de videos e geração de imagens
