Pull Request: Refactoring Invoice Module (Enhance Directory Structure, Naming, Data Types, Type Casting & Logic Flow)#6
Open
AbRahman-ra wants to merge 11 commits into
Open
Pull Request: Refactoring Invoice Module (Enhance Directory Structure, Naming, Data Types, Type Casting & Logic Flow)#6AbRahman-ra wants to merge 11 commits into
AbRahman-ra wants to merge 11 commits into
Conversation
…od, added currency enum and helper to calculate decimal points
This reverts commit f845ee5.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request: Refactoring Invoice Module (Enhance Directory Structure, Naming, Data Types, Type Casting & Logic Flow)
Description
This pull request generally add static type enhancements for the
Invoicemodule. Inspired from Java's Jackson, an object mapper that casts JSON/XML objects to POJOs (Plain Old Java Objects).We are doing a "minor" version of that, so that we can cast Moyasar Invoice Response to a PHP Object, in addition, we are taking advantage of PHP built-in data types and proper OO Principles, so that we have a better design and more predictable objects
One more issue that this PR has enhances is the naming; Calling a "DTO" from client side is not a good practice, since DTO are usually referring to the mappers inside the client's application. Thus, it was necessary to rename something like "CreateInvoiceDTO" into something meaningful from the client point of view, such as "CreateInvoiceRequest"
Since this change is a breaking one, I have updated invoice test cases with the new structure such that we still have a passing pipeline. In addition, I updated README, CONTRIBUTING & TODO so that we have a more accurate, detailed and well formatted documentation
Directory Structure
We are now classifying the project into
Invoice,Payment. etc...)Shared), anything used by all modules or the client will be hereTip
Note: Only Invocie modules is done, other modules are still on the old architecture
Each Module will have 2 main directories
Usecases
Flow
Tip
Note: For getting invoice by id, or canceling invoice, you don't need to create a request dto, just the invoice id as a string
Warning
In previous version, you would multiply the invoice amount by the currency minor unit (e.g, to issue an ivoice with 25 SAR, you need to pass 2500). THIS IS NOT NEEDED ANYMORE, the package will do that internally
InvalidArgumentExceptionwill be thrownApiResponse<Resposne>will be returnedApiResponse<null>will be returned, however, the resposne body as string as well as the status code will be included in the returnedApiResponseinstance for the user to handle themTip
We highly encourage to check the retuned response first
Other Notes