Olá, sejam todos muito bem-vindos a mais uma aula. E na aula de hoje, a gente vai começar a implementar o Xavon Architecture. A gente precisa entender por onde começar. Alguém tem ideia de por onde começar? Você sabe por onde começar? Por onde você começaria? Já te digo logo de cara que eu vou começar extraindo os casos de uso da aplicação. Lembra que o Arthur Coburn comenta justamente isso? Pense nos casos de uso primeiro. É isso, exatamente é isso que a gente vai fazer. Mas antes de começar né o antes de começar a extrair os casos de uso tudo mais é importante a gente a gente tá na mesma página e entender quais os tipos de caso de uso que a gente normalmente encontra na aplicação qual é a sua apropriação? Quais os tipos? Eu vejo 3, que inclusive foi utilizado lá no curso Fullcycle no projeto prático em Java da CodeFlix, quem fez em Java aprendeu isso lá também, mas eu vejo 3. O primeiro que é o caso de uso padrão que recebe um dado e retorna um dado. Vamos ver como é que ele é? Vamos fazer aqui junto. Já vou aproveitar aqui dentro, dentro do package principal e a gente já pode até meio que criar os pacotes onde ficarão os casos de uso. Ou seja, eu vou criar um package chamado application. Casos de uso da aplicação e pro hexagonal A gente vai deixar o domínio aqui dentro também Então, application Aqui dentro eu vou criar já Na verdade eu vou deixar na raiz do application Depois a gente muda Então, quais os casos de uso? O primeiro que eu falei para vocês é o useCase Eu vou colocar ele aqui como um abstrato, e tem dois parâmetros genéricos. O primeiro que é o parâmetro de entrada, o input, e ele tem um output. E aí a gente já define aqui o primeiro acordo. A gente define a primeira forma de trabalho, que é trabalhar com use case, onde cada caso de uso tem um input e tem um output declarado nele mesmo. Pode ser ali no package dele, se você tiver um package só por causa de uso, pode ser sim em algum outro lugar, mas cada caso de uso vai ter um input e um output, e aqui no Java ficou muito mais fácil depois que vieram os record classes. A gente não vai retornar agregado, a gente não vai retornar entidade, a gente não vai retornar objeto de valor, a gente vai retornar um input e um output para cada caso de uso porque o retorno e entrada de cada caso pode variar não necessariamente que é uma entidade que vai tornar e que é uma entidade que vai receber então por isso a gente já faz esse acordo para evitar bagunça de design segundo acordo então vamos colocar aqui oiro acordo é cada caso de uso tem um input e um output próprio. não retorna a entidade, o agregado ou objeto de valor. Ok? Segundo acordo. Segundo acordo. O caso de uso implementa o padrão command. O que esse padrão faz? Ele basicamente diz que cada classe deveria ter um único método público chamado execute. Onde vão as dependências? Se for parâmetros de entrada do método, vão no método, é o input. Se for dependência externa de um outro objeto, aí construtor da classe do useCase. Então vamos lá. input execute e retorna ele retorna um output e ele recebe um input e esse é o primeiro caso de uso ele recebe um input e ele retorna um output qual que é o segundo caso de uso? deixa eu copiar esse cara recebe um input e ele retorna um output. Qual que é o segundo caso de uso? Vamos lá, deixa eu copiar esse cara. O segundo caso de uso é o nullary use case. O que é o nullary use case? Ele não recebe parâmetro de entrada. Ele faz alguma coisa e retorna o que foi feito. E qual que é o terceiro use case? O terceiro use case é o unit use case. Ele só tem um input. Ele não tem um parâmetro de entrada, input. Ele tem um parâmetro de entrada e não tem um retorno. Ele só tem um input e não tem o output, o retorno. E esses são os três tipos de casos de uso que a gente vai utilizar. Acho que o Unity e o Nullary, não tenho certeza se a gente vai utilizar mesmo, mas são os casos de uso aqui que a gente normalmente utiliza e eu deixei como uma classe abstrata aqui, poderia ser uma interface eu deixei como classe abstrata porque normalmente o caso de uso ele ele implementa vai implementar essa classe abstrata e ele deveria ter só ela como uma classe base. Qualquer outra coisa deveria ser talvez uma interface ou uma composição, algo do gênero. Então, é por isso que eu particularmente gosto de deixar como católico trata para trazer essa constraint forte mesmo. Poderia ser uma sealed class? Poderia ser uma sealed class. Só que nesse caso eu não quero necessariamente controlar de fato todas as implementações que são permitidas para esses meus casos de uso. Eu não quero ter esse controle baixo nível para depois usufruir de algo como exhaustive check para switch case ou coisa do gênero. Então, por isso, um abstract class já funciona bem. Se você quiser fazer com interface, está tudo bem também. Ok? Então, por hora, é importante a gente ter em mente a anatomia dos casos de uso. E aí, na próxima aula, a gente vai começar a implantar, a isolar, a extrair os casos de uso que estão aqui implícitos dentro da aplicação para ir rumo ao hexagonal. Então é isso. Vejo vocês na próxima aula.