Transforming DBS PayLah! with Domain-Driven Design
In 2019, the e-wallet underwent an architectural change that included context mapping and defining microservices.
Launched in 2014, DBS PayLah! is a popular e-wallet in Singapore that runs on smartphones. As the app is bank agnostic — users who hold accounts with other banks can also use it — PayLah! has fundamentally transformed the way consumers make payments.
PayLah! as an everyday app for consumers
The PayLah! e-wallet is linked to the user’s mobile number, which in turn, is linked to a bank account of their choice. PayLah! can be used to make payments for online purchases, at retail outlets by scanning a QR code, and to make fund transfers between friends. PayLah! can also be used in other countries such as Malaysia and Thailand.
With over two million users and growing, many of our customers are also utilising PayLah! for their other daily needs, such as booking transport rides, ordering meal deliveries, and tracking credit card rewards.
PayLah!’s transformation journey from “A Big Ball of Mud”
At the backend, one of the numerous reasons why PayLah! remains a top e-wallet for many is its domain-driven design (DDD). But the app didn’t start out with DDD. Instead, PayLah! started with a monolithic architecture, and as it grew at an accelerated rate, it became a Big Ball of Mud for technologists. In 2019, PayLah! underwent a transformation journey, starting with the adoption of DDD, which I’ll be sharing more about in this article.
I will also touch on the challenges we encountered with the initial monolithic architecture, and how we worked with domain experts to create a shared model of the different systems and evolved PayLah! into one with an identified domain that’s aligned with business architecture.
A monolithic architecture
When I joined the team as an Application Lead for PayLah!, the multiple interconnected domains and their tightly coupled natures were initially overwhelming. This is partly attributed to how PayLah! was initially developed, which was as a monolithic application hosted within a single code repository.
With the rapid growth of its user base and the addition of multiple new features, the code base quickly devolved into a spaghetti code jungle. Predictably, this gave rise to various challenges around code maintainability, slowed deployments, decreased the speed to market, and greatly increased operational costs.
The challenges and roadblocks that the team struggled with included:
1) No test automation: There was no clear accountability in managing and maintaining test scripts and data.
2) Managing technical debt: There was no separation of responsibilities or efforts in place to address technical debt.
3) High overheads: Large teams were tasked to maintain business features, which culminated in a high utilisation of resources.
4) Complex deployments: Multiple teams worked on the same repository, leading to cumbersome processes. Code quality took a hit as a result.
5) Lack of governance: The use of a common API and code reusability practices were not implemented.
6) Service availability: There was no single point of contact responsible for ensuring that the service stays available.
Adopting Domain-Driven Design (DDD)
The original architectural style had tightly coupled requirements that spanned login and registration, payment, wallet management, and even partner integration. Everything resided within a monolithic context with no clear transactional boundaries. Moreover, all behaviours were encapsulated in a single, large service layer as seen in the diagram above.
A new approach was needed to better align software design with the business domain to support the future development of PayLah!. We decided to go with DDD, a software development approach that bridges the gap between Technology and Business for a more effective and cohesive software design.
Another benefit of DDD is how it can help organisations effectively handle complex issues. It focuses on the most important and valuable aspects of the business, instead of easily replaceable elements. This encourages investment in the most complex and valuable parts of the system, or the “core domain”, to deliver the greatest benefits.
There were three big motivations to adopt DDD with PayLah!:
1) Organisational structure: How teams are organised around the architecture is fundamental to how rapidly we can improve our product. The old approach could not deliver what we needed.
2) Refactoring the monolithic application: We wanted to develop a capability-based API and refactor the outdated monolithic architecture to a modern alternative that is easier to maintain and develop.
3) Microservice architecture: The software development ecosystem is constantly evolving with innovations in tools, frameworks, and techniques. This allowed us to adopt a microservices architecture to streamline business capabilities into individual, autonomous services.
Laying the groundwork
Transformation is not an event; it is a journey that is designed to achieve high-impact outcomes. We started by working with domain experts to understand the business. This allowed us to create a shared model of the domain with concepts and language that are meaningful to both technical and business stakeholders.
We focused on three key steps:
1) Establishing a ubiquitous language: As none of us had any prior experience in payments and mobile wallets, we first had multiple conversations with domain experts. This helped us grasp the business domain and associated business logic and laid a foundation for a ubiquitous language.
2) Context mapping: Correct boundaries are important for the seamless coexistence of systems and teams. The goal of bounded context is to protect the ubiquitous language by making sure that each term of the language has exactly one meaning to eliminate ambiguity.
3) Defining the microservices: The goal of a microservices-based architecture revolves around decomposing a system into a set of loosely coupled, yet coherent components. The best way to decompose bounded context into microservices is to find the right boundaries through experimentation. This meant that some mistakes were inevitable.
Considering the above principles, we were able to define domains and sub-domains that we had within the monolith. With the adoption of DDD, we developed a capability-based API to break the monolith app into a microservice application.
We preferred to start with bigger boundaries and decompose them later as we acquired more knowledge about the business. From our experience, complex domains such as core business systems (payment, wallet, cards) start with wider boundaries. Simpler ones such as supporting domains (notifications) were decomposed earlier.
DDD defining microservices
DDD advocates splitting the business into multiple domains. Each domain has its own bounded context which correlates to a microservice. Based on this, the target architecture for PayLah! was classified into service categories based on the use case of the feature:
1) Core services: Handles persistence of business data and applies business rules and other logic.
2) Business capability services: Enabling core services and aggregating information from different core services to enable functionalities.
3) Proxy services: Another approach to wrap business capability services in its own service.
Key principles for these microservices were as follows:
1) Each microservice/capability will be exposed via an API contract, regardless of choice of IPC (SYNC or ASYNC) mechanism.
2) APIs will change over time, and the appropriate version control would be maintained depending on the size of the change.
3) Communication between an API consumer and API service provider will be stateless.
4) Stateless authentication With JSON Web Tokens (JWT):
o JWT consists of the header, payload, and signature.
o One of the JWT primary use cases is to authenticate requests.
o Once a user has logged in, each subsequent request can include the JWT to access previously inaccessible or protected resources and services.
The outcomes of implementing DDD
The implementation phase of DDD focuses on building a software solution based on the models and maps developed in the earlier phases. This may involve creating a new system from scratch, or refactoring an existing monolithic application.
1) With the adoption of DDD, the business domain of PayLah! evolved to feature clear transactional boundaries and behaviours. Below is a sample domain model with clearly demarcated layers.
2) With ownership of domains aligned, we were able to promote adoption of Design and Delivery Principles aligned to their respective KPI/metrics in collaboration with Architecture, DevSec Ops and SRE teams (as presented below).
3. Given a lean squad with clear ownership and roles, we were able to achieve better alignment and worked faster than before (when we had multiple squads). We were also able to establish consistent metrics and progress reports (TTM, MTTD, MTTR, SLO, etc), with a clear roadmap of product development and mapping of company goals.
4. The result included more efficient product development with faster development cycles. Moreover, the new teams are highly knowledgeable and specialised in their fields, allowing us to successfully roll out new products with cutting-edge capabilities. Crucially, we managed to achieve these using fewer resources than before.
The successful transformation is evident from the growth of PayLah!:
1) A 69% year-on-year increase in transaction volume from 2020 to 2021.
2) An increase in monthly active users from 40% to 49% from 2019 to 2021.
3) The daily active users count increased by 54% from 2019 to 2021.
4) High customer engagement with a 73% increase in annual logins from 2019 to 2021.
As businesses evolve, new profit sources are evaluated, new opportunities are discovered, and business domains must change accordingly. Domain identification is an evolving journey where the domain model is revisited and refined.
Manish Parashar is the senior vice president of Consumer Banking and Core Engines Technology at DBS Tech India, and oversees all data and technology projects of the C2E (CBGT and Core Engine) business unit.
