Estrutura do projeto

Focos durante o desenvolvimento

Performance

Testes com faker

Notas de desenvolvimento

O código que será escrito tem a seguinte mentalidade:

UC consome os serviços, banco, CEP, PIX o que for, os serviços dão throw, mas o UC trata ex:

UC para salvar os dados de um user, se por alguma inconsistência da base deu um erro 500, o UC irá retornar para a controller apenas um “success” false, UC não deve dar throw, deve capturar o erro e tratar, salvar log o que for, mas a regra de negócio não pode morrer por inconsistencia de serviço externo a ela.

Implementação de serviço DEVE dar throw, serviço não trata o que deve acontecer caso der erro, serviço apenas garante que o processo dele mesmo não irá causar incosistencia, exemplo update de user seguido de alteração de tabela filha, se o update der erro deve ter um rollback de tudo, isso é responsabilidade da implementação do serviço, o serviço pode ter try catch, mas não deve ser ele que decide como deve ser tratado o catch em questão de sequencia do código, ainda mais lidando com sincronização, exemplo: não é porquê 1 registro deu erro ao tentar sincronizar, que deve morrer a sincronização como um todo, quem decide se deve continuar após um erro no código ou no serviço é o UC.

Quando um registro der erro de sync, separar ele na reponse dos que deram success, exemplo:

{

“success”: true,

“data”: [

{

“id”: 1,

“succes”: true

{

“id”: 2,

“success”: false,

“error”: “fabricante não encontrado.”

}

]

}

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.