Table of Contents
Craftgate
Craftgate allows you to manage virtual POSs (Vpos), payment, and e-money institutions from a single center while also facilitating payments through alternative payment channels such as APM (Alternative Payment Methods) and international payment integrations (hub, gateway).
Craftgate offers many value-added services simultaneously, such as payment collection with the QR code, closed-loop wallets, and smart and dynamic payment routing.
Payment Systems
Payment systems and payment gateways are highly specialized fields. They demand precision and require zero errors because they deal with handling money. In simpler terms, you’re working magic with money, and in a system that processes billions of dollars in transactions, every detail must be impeccably accurate down to the last cent.
Due to the precision and meticulousness required by the business, we decided to build Craftgate payment gateway using Hexagonal architecture. The most significant reasons for making this decision can be summarized as follows:
- Payment, by its nature, is a complex and challenging domain. Therefore, we wanted to make the domain code as understandable, testable, and maintainable as possible.
- Since we mediate payments from various payment channels, our integration points could differ (Rest, Soap, 3rd library, etc.). Therefore, we can easily integrate even very different integrations into the system.
- We carefully use the most up-to-date/secure version of our frameworks and libraries, so we wanted any changes not to break or affect the domain code.
- While building the business code, we wanted to postpone technical decisions as much as possible.
- We wanted to distinguish between codes with high and low change frequencies.
- We wanted newcomers to understand payment systems and the codebase quickly.
Of course, we can expand on the reasons mentioned above.
Hexagonal architecture may not be meaningful for every business or stage and may not be necessary for some companies. So, that’s why it would be better to remember that different architectures may be preferred, especially for the early stages.
When making this decision, we relied on our past experiences with payment systems and considered our experiences with other software development architectures. We had refactored and evolved the initial version for almost 3 to 4 years. We can say that this decision has added a lot to us over the years.
Hexagonal Architecture
We divide the Hexagonal architecture into two units: Domain and Infra.
Domain is the unit that contains the actual business code, ensuring the business’s healthy and correct growth. The domain includes core issues such as commission and vendor earnings calculations in the payment world.
“Payment is our business, and business is good.”
Conversely, infra is a unit that contains purely technological code, including rest endpoints we opened for payment collection, details like databases/Redis, etc.
Both units have their own dynamics and ways of working.
We can summarize the Hexagonal Architecture we use as follows:
Thanks to Lemi Orhan Ergin for the image.
Our domain code has no technology or framework-dependent classes/annotations, etc. Therefore, we write core Java in the domain. This turns the domain into code fragments that can be tested, read, and understood independently. This is business-driven, meaning it is a unit where the company’s direction is based on business decisions and can pivot accordingly. Therefore, it can change and evolve instantly.
Our infra codes are entirely technology-focused, where details such as rest endpoints and database operations trigger the domain. We can say that these are the areas with low change frequency. The rest of the endpoints we opened are almost the same as they were on the first day.
One of the biggest reasons for choosing Hexagonal Architecture was to separate frequently changing code from less frequent. We saw this vividly when we decided to use AWS’s OpenSearch service instead of the traditional ElasticSearch. 🙂 We could change this by simply changing a single class in the code. There were no changes in the domain code.
We can easily say that Hexagonal Architecture has made our lives easier in many ways. We can summarize these benefits as follows:
- We can make payment systems that are inherently complex, understandable, and manageable.
- We can easily add new integration points to the system. These can be a new bank’s virtual POS or one of the international payment methods.
- We can easily discuss the domain.
- We can test the domain on its own and validate the business.
- Know-how spreads much faster and more accessible within the team.
- We see domain code changes/decisions more transparent in pull requests and reviews.
