Agora, como a gente está usando o TDD, e eu pulei um pouco o processo, vamos pensar agora racionalmente o que a gente quer. E isso é super relevante para o TDD. Qual é o mês e o ano que eu quero gerar? Então, como eu estava falando, todo use case tem um input e um output. Esse input e output talvez seja o primeiro padrão que a gente está vendo aqui, que é o padrão DTO, que significa Data Transfer Object. Basicamente é um objeto que só tem propriedades utilizadas para transporte entre cabadas da aplicação. Essa é a ideia do DTO. Infelizmente, muita gente hoje, não infelizmente, cada um usa o que quer e é responsável por isso, usa a linguagem desorientada do objeto, mas com um domínio muito anêmico, ou seja, tem código procedural junto com DTOs. Só objetos que só têm dados. Aí o objeto se torna só uma estrutura de dados. Não tem a ver com um design orientado a objetos. Eu vou até salvar isso aqui. Espera aí. Aqui. Patterns.txt Então, qual é o input para que eu gere notas da minha empresa? O mês é 1 e o ano é 2022. Então, eu quero gerar notas fiscais de 2022. É isso. Tem mais uma informação. Regime. O regime. de 22, é isso tem mais uma informação regime o regime então em inglês a gente tem um nome que é muito estranho para isso muito estranho, mas é assim que se chama não sou contador então não posso afirmar com todas as letras mas a gente tem um type aqui que pode ser Acron, que seria por competência, ou Cache, que seria por caixa. Então, vamos supor que seja caixa, é o mais fácil. Vou passar o input para cá, para quebrar caixa. É o mais fácil. Vou passar o input para cá. Vai quebrar o teste. Peguei o output e vou validar o output. O que deveria ter nesse output se for um regime de caixa? Se eu olhar para o banco de dados, em janeiro eu recebi 6 mil reais. Logo, o que eu deveria ter? Olha lá. Eu espero que output at zero, ou seja, output é um array. Output at zero. Eu tenho uma propriedade chamada bait. output at zero, eu tenho uma propriedade chamada bait deixa eu só ver aqui se the syntax system type never, porque eu não eu não declarei aqui qual que é a saída, tá? deixa eu só botar um n aqui por enquanto para a gente não se prender nessas coisas antes vamos supor que eu já vou entregar essa data formatada eu não vou entregar em date, eu vou entregar com uma data formatada eu vou ter porque sim essa saída de dados me exige isso, a hora não é relevante enfim, 2022, 01,05. E aí aqui, a MAUF, 6 mil. Beleza? Essa seria a minha saída, se for caixa. Então, por regime. Por que eu não faço a competência na sequência? Porque eu estaria quebrando uma lei do TDD então a ideia do teste é eu devo escrever teste para detectar uma falha e em seguida fazer passar exatamente naquela falha sem escrever código a mais do que o necessário para fazer com que aquela falha seja resolvida, então se eu escrever mais falhas, eu estou quebrando uma das leis do TDD. Leis, maneira de falar, né? São só conselhos escritos pelo Bob Martin. E vamos lá. Aqui, então, eu tenho um input. Aqui eu tenho um output. All DTOI. Entrada e saída, tá? Type input. O que eu tenho de entrada? Maze, que é um number, year, que é um number. O que eu tenho de output? Basicamente, vou ter um output array aqui, vou ter vários outputs. Esse output vai ser composto de quê? De date, que nesse caso vai ser uma string, porque eu já quero só aquele formato e a mouse que vai ser um number. A importância de ter DTOs na entrada e na saída são padrões de praticamente transporte de dados. Isso faz com que você tenha uma fronteira bem no seu use case. Tá bom? E agora, como é que faz? Vamos pensar. Eu vou pegar cada um dos contratos, certo? Para cada um deles, o que eu vou fazer? Vou ter que pegar os pagamentos deles. Então, payments, connection query, select asterisco. Não se preocupe que a gente está escrevendo tudo misturado. A ideia é que a gente vai refatorar usando padrões de projeto. Essa é a ideia. Payments. Where are the contracts? É. Contracts. The contracts. E agora, na teoria, ali eu tenho o que eu preciso. Eu até vou te mostrar A saída As vezes botar um pouquinho de Output É legal para você ir vendo o que está saindo Mesmo que o teste quebre Mas você viu o pagamento saindo O teste quebra, não importa O que saiu errado Agora aqui, pensa comigo. Regime de caixa é baseado nos pagamentos que eu recebo. Muito bem, está fácil. Na teoria está fácil, porque o output que eu vou ter aqui é do tipo output array. é do tipo output array certo? então vou voltar aqui o meu output e aqui eu vou dizer assim para cada pagamento isso aqui depois vai virar domínio mas tudo bem output bom, primeira coisa é eu estou no mês de apuração Então vamos verificar Se Pagamento .date .getmonth Ou seja Ele Bom, vamos sair se for diferente Ele é diferente de Input month Só lembro de uma coisa, tá? Janeiro aqui é zero. Janeiro aqui é zero. Então, mais um. Aqui. Ou, payment date get full year é diferente de input year? Se sim, continua. Aqui embaixo, o que fazemos? Quer dizer, aqui eu estou no momento em que eu preciso reconhecer essa receita. Então, output push. Vou colocar aqui o date. Então, é payment.date. E a mouth, payment.mouth. Fechou? Isso aí. Roda o teste. Está certo? Não seiouse roda o teste tá certo? não sei, roda o teste por que não tá certo? porque eu trouxe a data inteira eu só quero a data formatada só um pedaço dela eu vou usar um negócio chamado eu sei que o moment já tá começando a entrar em desuso mas ele ainda vai ser útil para a gente aqui. Ó, moment format. Ano, mês, dia. E aqui, faltou fazer um parse. Por quê? Isso vem do banco de dados como string. Porque é do tipo numérica, é questão mais do posto é isso mesmo. Quando eu teste, passou o teste. Beleza? Você está vendo que está dando um erro de conexão? Não é um erro, é um ordem de conexão. Porque a gente tem que fazer o fechamento. Connection to end. Fechou? Fechou. Regime de caixa. Regime de competência vamos lá o regime de competência agora a coisa complica um pouquinho vou usar o termo em inglês escrever isso aqui é difícil é o termo melhor a gente usa um termo melhor pensa comigo quanto vai ser 6 mil reais É o termo melhor, a gente usa um termo melhor. Pensa comigo. Quanto vai ser? 6 mil reais em 12 períodos de reconhecimento, certo? Está aqui, 6 mil reais em 12 períodos, correto? Ou seja, começando em janeiro, de janeiro a dezembro. Então, em janeiro eu reconheço receita. Então, o que muda aqui para o Acro? Que eu tenho R$500,00. Em 1 do 1. Faz sentido? É como são origens diferentes do reconhecimento da receita? Então, tá bom. Roda o teste. Tá batido, não vai sair isso aí, vai passar no mesmo lugar. Agora aqui, o que a gente faz? Então, se, vou até fechar aqui, se input type igual a cache olha o código vai ficando ruim de propósito a ideia não é botar o type você pode fazer assim ainda cache ou acro aqui if input type igual a acro competência mas faz pensar eu já tenho o contrato certo se eu já tenho esse contrato eu vou ter que entender agora desse contrato como que eu faço a distribuição. Então, vamos pensar o seguinte, olha, eu vou começar reconhecendo pelo período, sei lá, vamos fazer um while aqui, enquanto o período for menor ou menor ou igual, vamos ver o que fica bom periods passa, tá bom então eu tenho que ver esse contrato tem 12 períodos se esse contrato tem 12 períodos como é que vai ser o nosso reconhecimento eu na teoria vou ter que usar um moment para pegar a data inicial e somar meses pegar data inicial e somar meses pegar a data e somar meses então vamos lá eu vou provisor uma data que é moment contract date .ed, por isso vou usar uma biblioteca vou somar o que? periods mais mais antes Vou somar o quê? Periods Mais mais Antes Porque no primeiro mês Eu vou usar 0 E vou incrementar Depois eu vou usar 1, 2, 3, 4 Até chegar em 12 Uma teoria É isso aqui Amalfi vai ser o quê? Contract Amalfi Dividido por Contract Periods Só que lembra que aqui Parse Float Agora temos dois Então, 6 mil reais Dividido por 12 períodos A 500 Data inicial e segue Lembrando que Isso aqui tem que estar presente aqui também deixa eu ver aonde pode ser aqui vai ser contract date a data provisionada está certa date a data provisionada, está certo date só que para viabilizar isso aqui date aí a gente tem a data certinha beleza? aqui se não eu saio, obtive e aqui então fica output push, o que? output push, date, moment, date, format, beleza, e aqui a mouth. Tá certo ou não tá certo? Não sei, vamos rodar o teste Quebrou lá Porque o input não foi cache Beleza, vamos ver o que ele reclamou Deixa eu ver se eu botei certo aqui Pera lá Deixa deixa eu ver... Este type... Botei certo? Por que eu botei errado? Vou botar string mesmo. Então, tivemos o output correto. Vamos ver se a gente está correto mesmo? Para esse teste ficar mais certo, o que a gente tem que fazer? Eu não vou fazer de todos, né? Mas na teoria, no mês 2, mês 3, mês 4, mês 5, mês 6, mês 7, 5, 6, 6. Zero. Ah, comecei zero. Está certo. Falhou. Ah, está. Não. Errou que viajei. Isso aqui tem que estar em outro lugar peguei o primeiro mês por isso que não vou fazer pro segundo mês 2 na real tava certo mês 2 poderemos ter outras compras também tá certo só pro mês de janeiro Aqui a gente fica em fevereiro E assim sucessivamente Podia haver um mês que não tenha nada Enfim, tem várias coisas que a gente poderia fazer aqui Pessoal O que vocês acham desse código? Um código Ruim Se a gente pensar, ele deixa a desejar em vários sentidos. Ele mistura regras de negócio com conceitos de banco de dados, por exemplo. Então, a gente, ao mesmo tempo que está obtendo dados do banco, a gente está executando regras de negócio, como aqui, como aqui. A gente está lidando com conexão. Então, isso acaba quebrando um princípio do SOLID, que é o tal do Single Responsibility Principle. Então, eu vou citar alguns princípios do SOLID aqui. Então, até vou colocar aqui. SOLID, então, Single Responsibility Principle, que diz o seguinte. respond stability principle diz o seguinte devemos separar coisas que mudam por motivos diferentes o que muda por motivo diferente aqui? tudo, né? conexão muda por motivo diferente porque eu posso mudar o servidor eu mudo a conexão a Conexão muda por um motivo diferente. Porque eu posso mudar o servidor, eu mudo a conexão. A obtenção de dados muda, porque eu posso mudar o nome da tabela, eu vou mudar esse trecho do código. O tipo de regime mudou, eu mudo aqui também. A forma de apuração, se é por pagamento, se é por caixa, por pagamento, ou por competência, muda. Eu estou o tempo todo mudando e isso faz com que o nosso código se torne frágil a nossa refatoração ela vai envolver agora justamente muitos padrões e o que seria a primeira coisa que eu separaria aqui lembrando que eu já tenho o teste o teste está funcionando então garantidamente não vou ter problemas com comportamento com regressão desse comportamento até porque isso aqui é uma coisa super crítica, super importante para uma empresa você não pode fazer errado você não pode deixar com que uma refatoração estrague uma possível regra de negócio que você tinha implementado