Feat/idr rate aggregator

[andhikakrstn3]

Summary

• Implement single REST endpoint GET /api/finance/data/{resourceType} aggregating 3
  Frankfurter API resources
• Apply Strategy Pattern with IDRDataFetcher interface and 3 concrete implementations
• Use FactoryBean<WebClient> for API client construction
• Fetch all data once at startup via ApplicationRunner, store in thread-safe immutable
  DataStoreService
• Calculate personalized USD_BuySpread_IDR (spread factor: 0.00333)

Architectural Rationale

1. Polymorphism Justification (Strategy Pattern)

The Strategy Pattern was chosen over a simpler if/else or switch block because each of the
three data resources requires fundamentally different API endpoints, response parsing, and
transformation logic. By encapsulating each variation behind a common IDRDataFetcher
interface, we achieve:

• Extensibility (Open/Closed Principle): Adding a new data resource requires only creating
  a new IDRDataFetcher implementation annotated with @Component. No existing code in the
  controller, runner, or other strategies needs to change.
• Maintainability: Each strategy class is self-contained and independently testable. A bug
  fix or logic change in one strategy has zero risk of impacting others.
• Elimination of conditional logic: The controller delegates using a simple map lookup by
  resourceType string, with no manual branching.

2. Client Factory (FactoryBean)

FrankfurterWebClientFactoryBean implements FactoryBean<WebClient> to encapsulate the full
construction and configuration of the WebClient instance within Spring's bean lifecycle.
Benefits over a standard @Bean method:

• Encapsulation of complex creation logic: The FactoryBean pattern clearly separates the
  "how to build the client" concern into its own dedicated class.
• Transparent bean registration: Spring treats the product of getObject() as the actual
  bean. Consumers inject WebClient directly without knowing a factory is involved.
• Singleton management: The isSingleton() method ensures Spring caches and reuses the
  same WebClient instance across all strategy classes.

3. Startup Runner Choice (ApplicationRunner)

DataInitializationRunner implements ApplicationRunner to fetch and cache all exchange rate
data at startup. Advantages over @PostConstruct:

• Full Spring context guarantee: ApplicationRunner executes after the entire application
  context is fully initialized. @PostConstruct runs during bean initialization, where dependent
  beans may not yet be ready.
• Fail-fast behavior: If the Frankfurter API is unreachable, the application fails
  immediately at startup with a clear error.
• Immediate responsiveness: Data is pre-loaded into an immutable in-memory store, so every
  API request is served instantly from memory.
• Access to ApplicationArguments: Enables future flexibility such as passing custom
  parameters via command-line.

Personalization

• GitHub Username: andhikakrstn3
• ASCII Sum: 1333
• Spread Factor: (1333 % 1000) / 100000.0 = 0.00333

Test Plan

• Unit tests for all 3 strategy implementations (6 tests)
• Integration test for startup data loading and endpoints (5 tests)
• mvn verify passes (11 tests total)