[Discussão] Organização do Repositório

[NicolasPereira]

Analisando a estrutura do projeto, notei algumas coisas que me incomodaram um pouco! Ao ver toda a estrutura, não diz sobre o negócio, temos que entrar dentro das pastas para saber exatamente do que se trata a aplicação.

Alguns pontos que me incomodaram por exemplo é o diretório ValueObjects geralmente o ValueObject é vinculado a um Domínio da aplicação.

Gostaria de sugerir a seguinte estrutura, dividindo alguns pontos em contextos e gostaria que vocês analisem pra ver se faz sentido.

src
-- Core
       Facades
         Larapix.php
      LaraPixService.php
      LaraPixServiceProvider.php
      LaraPixContract.php

-- Charge
        Charge.php
        Contracts
          ChargesContract.php
        Exception
          ChargeAlreadyCreatedException.php
          ChargeNotFoundException.php
        Services
          ChargeService.php
        ValueObjects
-- Customer
        Customer.php
        Contracts
          CustomerContract.php
        Exception
        Services
          CustomerService.php
        ValueObjects
-- Refund
        Refund.php
        Contracts
          RefundsContract.php
        Exception
        Services
          RefundService.php
        ValueObjects
-- Payments
        Payments.php
        Contracts
          PaymentsContract.php
        Exception
          PaymentMethodNotAcceptException.php
        Services
          PaymentService.php
        ValueObjects
          Pix.php
          QrCode.php

Pontos positivos com essa mudança:

1. Core, teremos o Core da aplicação separado! Dessa forma se precisar adicionar novas funcionalidades ao contexto do LaraPix fica mais fácil
2. Temos cada Contexto separado e com suas responsabilidades, se num futuro precisar remover um contexto ele está desacoplado e todos seus arquivos separados.
3. Os ValueObjects vão ficar separados por Contexto, ou seja vamos saber exatamente de qual contexto era cada Valor de Objeto criado.
4. Contratos separados por contexto, caso tenhamos novos contratos ele ficara organizado por contexto.
5. Services separados, dessa forma podemos implementar o principio de Single Responsability no projeto e criar por exemplo: ChargeFindByIdService ChargeCreateService e ChargeFindAllService, dessa forma cada serviço teria responsabilidade única e estaria dentro do seu contexto.
6. Separar as exceptions, as vezes podemos ter exceptions com nomes parecidos, dividindo por contexto ficaria mais fácil saber de onde ela pertence.
7. Teremos uma ''arquitetura'' do projeto um pouco mais limpa, qualquer pessoa que ver a nossa estrutura conseguirá entender que é relacionada a algum produto de pagamento, pois ela vai conseguir visualizar cada Contexto

Quão custoso sera essa implementação ?

Pelo fato de a codebase já possuir testes, acredito que a refatoração será fácil pois será afetada apenas os namespaces e o PHPStorm resolve isso muito fácil.

Não realizei a divisão de diretório seguindo a fundo a ideia de DDD, de criar uma camada para Application, Domain, Infra e Presentation pois acho que seria um esforço muito grande para o que o projeto resolve.

Fico no aguardo do retorno e participação de todos para essa decisão.

[DanielHe4rt]

Creio que seja uma boa migrarmos pra essa estrutura, já que os dominios são bem distintos e o código já foi planejado pra isso.

Podemos terminar as endpoints, e antes de dar a release subimos um PR pra organizar a nova estrutura. O que acha?

[NicolasPereira]

Concordo, acredito que podemos montar todos endpoints e garantir o funcionamento, até mesmo pra vcs lançarem a Feature ai na Liuv e dps organizamos a nova estrutura

[lucascbittencourt]

Acredito que esta mudança vai agregar muito na arquitetura do projeto deixando bem claro oque esta acontecendo em cada lugar sem a necessidade de abrir cada pasta, além de ficar mais facil de manter o projeto utilizando esta estratégia.

Sobre a mudança ser apenas depois do lançamento de todos endpoints eu acredito que como temos testes para toda a aplicação e seria uma mudança apenas de namespace seja possivel realizarmos tal ato em parelelo ao desenvolvimento para que quando for lançado a feature ja estar seguindo com uma arquitetura mais clara e objetiva.