System Architecture
Interactive diagram of the Mass platform. Hover over any service to see its dependencies and connections.
Design Patterns
Core architectural patterns that enable the platform's flexibility and multi-provider support.
01 Adapter Pattern
Every external partner is abstracted behind an adapter interface. Each partner gets its own implementation module with isolated facades, mappers, and config. Partner-specific types never leak into domain models.
TreasuryAdapter → WiseTreasuryImpl
TreasuryAdapter → TenetTreasuryImpl
02 Factory Pattern
Runtime adapter selection via Context enum. Each treasury or account is tagged with a context that determines which banking partner handles it. Spring auto-injects all implementations via Map<String, T>.
Context.TENET → tenetAdapterImpl
Context.WISE → wiseAdapterImpl
03 Facade Pattern
Three-layer facade abstraction: DB facades wrap JPA repositories, OpenSearch facades wrap search/cache, and common facades wrap cross-service HTTP clients with error handling.
Service → SearchFacade → OpenSearch
Service → CommonFacade → RestTemplate
04 Domain Isolation
Domain models have zero dependencies. JPA entities are separate classes in db modules. Three mapper layers transform between partner APIs, domain models, JPA entities, and search documents.
Domain → EntityMapper → JPA Entity
Domain → DocMapper → SearchDoc
05 Multi-Layer Retrieval
Strategy-based retrieval: PREFER_CACHED reads from OpenSearch with async reload, FORCE_RELOAD goes to PostgreSQL, and DEFAULT uses smart TTL-based selection for optimal performance.
RetrievalStrategy.FORCE_RELOAD
RetrievalStrategy.DEFAULT
06 Module Architecture
Every service follows the same Maven multi-module pattern: adapter, adapter-impl-{partner}, core, domain, db-postgres, opensearch, common, web. Scales from 3 modules (MFA) to 16 modules (Treasury).
{svc}-adapter → {svc}-adapter-impl-*
{svc}-db-postgres → {svc}-opensearch