The latest articles on DEV Community by Allef Santana (@garug). https://dev.to/garug https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F784062%2Fc95aab43-0e28-4e6a-8f07-5de4bbe0fc6e.jpeg https://dev.to/garug en Allef Santana Fri, 05 Jan 2024 18:36:18 +0000 https://dev.to/garug/minhas-estruturas-de-arquivos-3h6l https://dev.to/garug/minhas-estruturas-de-arquivos-3h6l <p>Essa postagem busca exemplificar o que eu uso em uma aplicação, independente de linguagem, para monolitos é necessário algumas abstrações a mais para organização.</p> <p>O principal são 3 paths<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>├── domain ├── ports ├── infra </code></pre> </div> <h2> Domain </h2> <p>Aqui fica a parte principal da aplicação</p> <p>O domain possui obrigatoriamente dois outros paths<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>├── domain │ ├── entities │ ├── usecases </code></pre> </div> <h3> Entities </h3> <p>Representa as assinaturas de estruturas da aplicação. Aqui entram classes, dicionários, tipos, interfaces, tudo que represente um dado utilizado na aplicação.</p> <p>Exemplos:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>├── domain │ ├── entities │ │ ├── User │ │ ├── Address │ ├── usecases </code></pre> </div> <h3> Usecases </h3> <p>Dado uma entidade, é uma ação. A nomeclatura de um usecase deve <br> ser representada por um verbo e uma entidade</p> <p>Todo usecase deve possuir a função <code>execute</code>, com sua forma mais básica mas pode possuir outras funções que ainda façam sentido dado o nome do usecase</p> <p>Usecases podem ter como dependência outros usecases e ports</p> <p>Exemplos:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>├── domain │ ├── entities │ │ ├── User │ │ ├── Address │ ├── usecases │ │ ├── FindUser │ │ ├── CreateUser │ │ ├── ChangeUserStatus </code></pre> </div> <p>Exemplos de código<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight java"><code><span class="n">changeUserStatus</span><span class="o">.</span><span class="na">to</span><span class="o">(</span><span class="n">newStatus</span><span class="o">)</span> <span class="n">findUser</span><span class="o">.</span><span class="na">byId</span><span class="o">(</span><span class="n">id</span><span class="o">)</span> <span class="n">findUser</span><span class="o">.</span><span class="na">withFilter</span><span class="o">(</span><span class="n">filterUser</span><span class="o">)</span> <span class="n">createUser</span><span class="o">.</span><span class="na">execute</span><span class="o">(</span><span class="n">user</span><span class="o">)</span> </code></pre> </div> <h2> Ports </h2> <p>Todas as integrações e comunicações</p> <p>O ports possui obrigatoriamente dois outros paths<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>├── ports │ ├── <span class="k">in</span> │ ├── out </code></pre> </div> <p>Ambos <code>in</code> e <code>out</code> podem possuir paths para cada responsabilidade, separando em ferramentas ou contextos específicos, dentro de cada contexto específico pode existir toda uma estrutura que faça sentido aquele contexto, por exemplo requisições precisam ser <strong>sanitizadas</strong> e/ou <strong>adaptadas</strong> antes de um usecase ser chamado</p> <p>O arquivo dentro de port pode ser apenas uma assinatura a ser provida pela infra</p> <h3> In </h3> <p>Todo dado que entra na aplicação de alguma forma.</p> <p>Receber, Ler, Consumir. Essa é a porta de entrada</p> <h4> Contextos específicos comuns </h4> <h5> http </h5> <p>Representa requisições http recebidas pela aplicação</p> <p>Exemplo:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>├── ports │ ├── <span class="k">in</span> │ │ ├── http │ │ │ ├── UserHttp │ │ ├── ReadUsers │ ├── out </code></pre> </div> <p>Nesse exemplo, UserHttp possuirá todas as requests possíveis relacionadas a usuário e ReadUsers é uma interface que será provida em algum outro lugar da aplicação (pode ser uma leitura de banco, pode ser uma integração com outro serviço)</p> <h3> Out </h3> <p>Todo o dado que sai da aplicação de alguma forma.</p> <p>Escrever, Produzir, Salvar, Notificar. Essa é a porta de saída.</p> <h4> Contextos específicos comuns </h4> <h5> Notifications </h5> <p>Eventos ou mensagens de notificação. Assim como os usecases, o nome de cada notification deve fazer sentido. Toda <code>notification</code> implementa o padrão de <a href="https://en.wikipedia.org/wiki/Observer_pattern#:~:text=Article%20Talk,calling%20one%20of%20their%20methods.">Observer</a> através de uma interface em comum <code>Notification</code></p> <p>Exemplo:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>├── ports │ ├── <span class="k">in</span> │ ├── out │ │ ├── notifications │ │ │ ├── OnUserSaved │ │ ├── WriteUsers </code></pre> </div> <h2> Infra </h2> <p>Toda a parte de configuração da aplicação, possuind dois paths<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>├── infra │ ├── config │ ├── providers </code></pre> </div> <h3> Config </h3> <p>Tudo referente a configuração</p> <h3> Providers </h3> <p>Prove as implementações de assinaturas em <code>ports</code></p> architecture