The Evolution Journey of Danggeun Pay's Backend Architecture

The Danggeun Pay team's backend started as a small Money project and underwent three major structural changes as the service expanded.

Initially, they used Layered Architecture (Controller-Service-Repository) to quickly launch the money transfer feature, but as features and the team grew, dependencies between Services became entangled, making testing and refactoring difficult. As Services took on validation, authorization, and even cross-cutting concerns, technical debt accumulated.

To solve this, they introduced Hexagonal Architecture, separating things into domain, usecase, and adapter.

• domain: core rules with no framework dependency
• usecase: user scenarios such as transfer, top-up, and refund
• adapter: DB, message broker, external APIs, and Web/Batch/Admin input and output

The transition was carried out gradually using the Strangler Fig Pattern and Feature Toggle. As a result, business logic was separated from technical details, and coupling between modules decreased, greatly improving maintainability and testability.

However, packing multiple domains into a single project revealed new problems. The Adapter module accumulated numerous implementations such as banners and points, and deploying money-api ended up deploying unrelated services together. Hexagonal architecture alone wasn't enough to guarantee boundaries between domains and deployment independence.

So they expanded again into a Monorepo structure based on Clean Architecture. The core goals were as follows.

• Domain modularization and explicit dependencies between domains
• Making implementation swaps and testing easy through dependency inversion
• Securing deployment independence
• Strengthening testability

The new structure was organized into six modules: bootstrap, core, infrastructure, library, platform, and usecase. In particular, by separating domains into core:{domain}:domain and core:{domain}:data, and combining only the necessary modules in bootstrap, independent deployment per service became possible.

This change was not merely a structural reorganization but became the foundation for boosting both development speed and operational stability at the same time. Lines of code increased by 192% year-over-year, but perceived build time did not increase, and with the addition of release reporting and runbook automation, problem-solving and engineering maturity spread across the entire organization.

Ultimately, the core of this journey came down to one thing: architecture must evolve alongside service growth, and the team must choose the structure that best solves its current problems.