Apply aggregation pattern to app/data #363
Closed
Conversation
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
added 2 commits
July 23, 2021 16:21
JeevenDhanoa
force-pushed
the
data-sources-aggregation
branch
from
aec6132 to
a9ae3e6
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
What does this PR do?
This PR restructures the code in
app/data/__init__.pyto implement an aggregate pattern. In this example, the DataSources class is the aggregate's root, while the three location service classes form the aggregate's boundary, stored in the__DATA_SOURCES_MAP dictionary. I made these changes by adding this DataSources class in
app/data/__init__.py, making the data sources dictionary private to that class, and updated references to this dictionary and it's accessor method in bothapp/main.pyandapp/routers/v2.py. I updated the existing accessor method, and added a new one to accommodate code in v2.py which required access to the entire dictionary. By doing this, the location services are no longer publicly accessible through the data sources dictionary, and the bounds of the aggregate pattern are maintained.Why make these changes?
Since multiple parts of the code (main, routers/v2) all need access to the different location services, it seems intuitive to group these services up through an aggregate pattern, where the new DataSources class is the publicly visible root that can access all of them. Creating an aggregate and using it in this way helps maintain the constraint that only one location service will be used at any given time, since the primary accessor method of the aggregate root will only return a single location service. I chose the name of DataSources for the aggregate root because it is representative of the aggregate itself, which maintains a dictionary of location services in its boundary which serve as data sources for the API.