Hello folks,
In this article, I will discuss the best possible approach to start building any fintech product. We will see how this approach will tackle common fintech issues at the early development phase. It will also help us make the right decisions and define the appropriate strategy to meet business objectives.
After working for more than 4 years in the Fintech domain, I have encountered many problems. Fintech applications face. As we know that the business structure of the Finance or Fintech domain is multi-layered, or we can say the multi-service-oriented environment. And to achieve the E2E objective, all layers should behave smoothly and accurately. After doing some analysis, I have broadly classified these problems into two parts-
- The biggest requirement or challenge of a Fintech application is that each of the components of such a multi-service-oriented application should work in isolation as well as perform in unity with other components to achieve the required functionality of the application. So that the business logic remains intact even if any of the components goes down.
- Each component of our multi-service-oriented application should be flexible enough to make changes from time to time. For example, if trade reporting services replace the existing database such as Cassandra with Elasticsearch, then there should not be any impact on any other component as well as the entire business logic.
Before going into the details on the problem mentioned above, I will discuss a silver bullet solution or architectural pattern that gives us the flexibility to design your application elegantly, irrespective of its size or complexity. Whether it is PoC, MVP, or a large multiple-service-oriented application. This pattern is known as Hexagonal Architecture.
What is Hexagonal Architecture
The hexagonal architecture, or ports and adapters architecture, is an architectural pattern used in software design. It aims at creating loosely coupled application components that can be easily connected to their software environment using ports and adapters. This makes components exchangeable at any level.
From the above architecture diagram, the entire application/platform is loosely coupled into three components: Adapters, Ports, and Core application.
Components of hexagonal Architecture
Adapters: This is the outermost layer of this architecture. The job of each adapter varies depending upon their need and utility.
Ports/Interfaces: This is the middle layer component of this architecture which resides between the application core and the adapters
Core application: This is one of the important components of the architecture that handles the application’s core business logic.
Each adapter is connected through the ports. And the adapters (via ports) communicate with the core application. There can be one or more adapters in your application. And each adapter is entirely independent and isolated in nature from the other adapters. The adapters can be input or output. Input adapters are the ones who take information from the end-user or service, transform the input to a domain-specific message, and forward the transformed message to the core application via ports. Similarly, the output adapters are needed to receive notifications from core applications via ports and send the message to the end-user or service in the required format.
Ports are the middle layer that rests between your core application and adapters. The core application is surrounded by ports/interfaces capable of interacting with any kind of adaptor. When designing an interface, we should keep in mind that the interface should be generic and adaptable. For example, we can use the Kafka queue as a standard interface for our application. Because they have multiple connectors and mechanisms to connect with Kafka brokers.
The core application is the centre of this architecture, which holds the entire business logic. The core application is the one that actually processes the request and generates the output to different adapters. While designing the core component, we have to select the right strategy & design pattern like DDD(Domain Driven Design), CQRS, Event Sourcing, etc. To make the application highly cohesive, modular, flexible, resilient, and fault-tolerant.
For example, we can take an analogy from our computer system, which can be a good candidate for Hexagonal architecture. The core application would be the computer itself. The ports can be your USB port, Audio/Video port, VGA/HDMI port, etc. And the adapters can be peripheral devices such as Mouse, Keyboard, Printer, Pen-Drive, Additional Monitor, etc.
Now move on to our problem statements, how hexagonal gives us a silver bullet solution for each type of application. Whether it is a small size (MVP) or an extensive application, we can take advantage of this architecture and fix the maximum problem initially.
The first problem was how to make a component genuinely independent of each other.
With the help of this architecture, we can design our application genuinely independently in nature. So if any adapter goes down or has some problem, then there is no impact on the core application and other adapters. Because this architecture gives us the flexibility to design each adapter separately and integrate it with the system via port/interface. For example, if an SMS adapter has some issue, just disconnects it from the port, and the system will function as it is without any logical impact.
The second problem revolves around whether we need to change any significant infrastructure, like replacing an existing database with another.
This architecture ensures that any adapter/core-engine needs any significant changes like replacing database/infrastructure or integration of any third-party service. The other adapters, as well as the core engine, will remain intact. For example, if we want to replace the currently running Oracle database with the Microsoft SQL Server database in DB adapter. We can do it seamlessly without any impact on other components. Similarly, if we want to replace core engine frameworks like migrate from Reactive Spring to Akka. We can achieve this without even impacting on any other adapters and interfaces. So, in a nutshell, we can say that we will conduct a truly component-level independent, flexible design, whether it is components or infrastructure.
Apart from these core benefits, we can design our new application with high modularity, defined in three dimensions: Structural, Operational, and Development.
Structural modularity:
Structural modularity means designing the application around business capabilities and not the technologies, with teams specialized in business domains and not technical capabilities. Under this architecture, we discuss and develop the system’s business model in business people language like in Domain-Driven Design (DDD). We only focus on the business domain and its complex logic using the ubiquitous language.
Functional modularity:
There should be minimal dependencies between the individual components of the application so that availability and performance are not impacted.
Modern applications are developed in the Agile way. And with this way of the development process, continuous delivery of new features and enhancement on the product or application (weekly, monthly or quarterly). Each component has its own delivery or deployment cycle. And thus, the components should be deployed so that they should not impact the deployment and delivery of other components in the entire system. This reduces operational maintenance.
When the operational coupling is high between the components, in that case, there are chances that changes in core components of the system impact the other components of the system. Therefore, in this case, due to operational coupling, it further requires extensive testing of the components, which again is a very painful and complex process because all this is directly related to time and cost.
Good operational modularity reduces the runtime dependencies between critical components of the entire system with the other components. This significantly reduces the system cost and time.
Development modularity:
Components with development modularity have minimal dependencies at the software level so that changes are developed, deployed, and tested without impact on the rest of the components. It will also give us the flexibility to assign each component to a separate team or individual for the development based on component size and complexity. Such flexibility also gives us space for better ways to implement an agile SDLC process to smoothly develop the entire application.
The life of the financial systems will be much longer than that of the technology on which they are being built.
Today’s solutions, standards, and patterns will be completely outmatched within a few years. This would make it necessary to evolve the applications with the changes in the available technologies, but given that the core systems support the critical processes for the financial institutions, any attempt to update the technological platform on which they are developed will meet significant resistance due to the risk involved unless such change is enabled through a correct design and by isolating elements of the business logic from the technological platform itself. If this is not achieved, it will pose a serious risk of technological obsolescence for systems. It would force financial institutions to support technologies long after they have been overcome, with the high cost that this can entail.
Use of the hexagonal architecture for the development of modular applications and with long life cycles.
The hexagonal architecture helps us develop applications with the modular characteristics required for an excellent time to market and achieve the expected service lifespan in core applications, avoiding the obsolescence of the technology on which they are built.
The hexagonal architecture is a well-known architectural pattern that produces applications loosely coupled from the technical environment and from other applications by isolating our application’s data and business logic from the outside through adapters.
In Knoldus, we have built a sample trading application based on this hexagonal architecture. You can get this full-fledged running app from here.
JOIN OUR FIRST VIRTUAL FINANCIAL SERVICES WEEK 2021
We invite you all to join and change your standpoint when it comes to the FinTech World. This week will give you a 360-degree tour of everything you need to know while working with Financial Technologies.
Be our Guest: https://lnkd.in/gFh2E84x
Know more details: https://lnkd.in/gcYBrcDq