Implement Check Order Payment Status API

[italopessoa]

Create an endpoint that returns Order Payment status based on Order Id

• Create a new GetPayment method on PaymentRepository to get payment details using payment ID
• Get Order details from OrderRepository
• Create a method on PaymentService to get PaymentStatus by ID, the payment ID can be found on the Order entity
• Return payment Status

it doesn't need to call MercadoPago gateway

[italopessoa]

graph LR
  subgraph Presentation Layer
    A[API Controller]
  end
  subgraph Application Layer
    B[Payment Status Use Case]
  end
  subgraph Domain Layer
    C[Payment Repository]
    D[Payment Entity]
  end
  subgraph Infrastructure Layer
    E[Payment Gateway]
  end

  A --> B
  B --> C
  C --> D
  C --> E
  D -.-> C
  E -.-> C

Explanation:

• Presentation Layer:
  • API Controller: This is the entry point for the API request. It receives the payment ID from the request and delegates the task to the Use Case.
• Application Layer:
  • Payment Status Use Case: This is responsible for handling the business logic of retrieving the payment status. It interacts with the Payment Repository to fetch the payment details.
• Domain Layer:
  • Payment Repository: This is an interface that defines how to interact with the data storage mechanism for payment details. It can be implemented using a database or any other persistence mechanism.
  • Payment Entity: This represents a payment in the system. It contains data like payment ID, status, amount, etc.
• Infrastructure Layer:
  • Payment Gateway: This is a third-party service that handles the actual payment processing and status updates. The Payment Repository interacts with the gateway to retrieve the latest status.

Flow:

1. The API Controller receives a request with a payment ID.
2. The API Controller calls the Payment Status Use Case, passing the payment ID.
3. The Payment Status Use Case uses the Payment Repository to fetch the payment details.
4. The Payment Repository interacts with the Payment Gateway to retrieve the latest payment status.
5. The Payment Gateway returns the payment status to the Payment Repository.
6. The Payment Repository returns the payment status to the Payment Status Use Case.
7. The Payment Status Use Case returns the payment status to the API Controller.
8. The API Controller returns the payment status to the client.

Benefits of Clean Architecture:

• Loose Coupling: The layers are independent of each other, allowing for easier maintenance and modifications.
• Testability: Each layer can be tested independently.
• Flexibility: The system can easily adapt to changes in the implementation details of specific layers.
• Maintainability: Changes in one layer are less likely to affect other layers.

This is a basic example, and you can adapt it to your specific needs by adding more layers or components. The key is to follow the principles of clean architecture to create a maintainable and scalable system.

[italopessoa]

@coderabbitai create mermaid sequenceDiagram graph

[coderabbitai[bot]]

[!TIP] For best results, initiate chat on the files or code changes.

@italopessoa Here's the Mermaid sequence diagram based on the architecture and flow you described:

sequenceDiagram
    participant AC as API Controller
    participant PSC as Payment Status Use Case
    participant PR as Payment Repository
    participant PE as Payment Entity
    participant PG as Payment Gateway
    participant Client

    AC->>PSC: Receives request with payment ID
    PSC->>PR: Calls with payment ID
    PR->>PE: Fetches payment details
    PR->>PG: Requests payment status
    PG-->>PR: Returns payment status
    PR-->>PSC: Returns payment details and status
    PSC-->>AC: Returns payment status
    AC-->>Client: Returns payment status

This diagram illustrates the sequence of interactions between the different components in your system, following the principles of clean architecture. You can adjust or expand this diagram to include more details or additional components as needed.