feat/idr-rate-aggregator-habibullah-dzaky#175
Open
habibullahdm wants to merge 1 commit intoallobankdev:mainfrom
Open
feat/idr-rate-aggregator-habibullah-dzaky#175habibullahdm wants to merge 1 commit intoallobankdev:mainfrom
habibullahdm wants to merge 1 commit intoallobankdev:mainfrom
Conversation
…ers, services, integration modules, configuration, exception handling, DTOs, and tests.
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.




The Strategy Pattern was implemented to decouple the resource processing logic from the main service layer. While a conditional block (if-else or switch) would suffice for current requirements, the pattern provides:
Open/Closed Principle: New resource types can be added by simply creating a new strategy class without modifying existing service logic.
Separation of Concerns: Each strategy encapsulates the specific parsing and validation logic for one resource, preventing the service layer from becoming a "God Class."
Testability: Each strategy can be unit-tested in isolation, reducing the complexity of testing the entire service flow.
A FactoryBean was chosen to manage the construction of the external API client for the following reasons:
Complex Initialization: The client requires sophisticated setup (e.g., custom interceptors, specific timeouts, and SSL configurations) that is cleaner to encapsulate within a dedicated factory class rather than a bloated @bean method.
Encapsulation: It hides the "how-to" of client creation. If the underlying library for the client changes (e.g., switching from RestTemplate to WebClient), the change is localized to the factory.
Control over Lifecycle: FactoryBean provides a more robust way to handle singleton vs. prototype instances and asynchronous initialization if required by the external dependency.
The choice of ApplicationRunner over @PostConstruct for initial data ingestion is intentional because:
Context Readiness: @PostConstruct triggers before the Spring ApplicationContext is fully refreshed. If the ingestion process requires interaction with other beans or the database, it may lead to NullPointerException or incomplete transactions.
Application Arguments: ApplicationRunner provides native access to command-line arguments, allowing us to pass specific flags (e.g., --skip-ingestion) during startup.
Graceful Failure: Unlike @PostConstruct, which can block the entire bean creation lifecycle, an ApplicationRunner ensures the application is up and running before the heavy lifting of data ingestion starts.