[C4GT Community]: Implement a repository pattern using sqlite storage for GeolocationQueryService

codecakes commented 1 month ago

Ticket Contents

Description

Issue #12 covers a high complexity objective to implement /geo api endpoint. In order to list facilities, implement a repository to be consumed from GeolocationQueryService.

Background:

The project has 3 primary levels:

IO layer: all infrastructural/mutating transactions. --> We want to implement repository storage here.
application services: services that consume the domain layer and are consumed by the IO layer.
domain: the ƒat business logic. --> We want to define interface signatures here.

The project src directory contains the following:


xcov19
├── app: Contains web framework, application services, routes, dto related modules.
│   ├── auth.py
│   ├── binders.py
│   ├── controllers
│   │   ├── diagnose.py
│   │   └── geolocation.py
│   ├── docs
│   │   └── binders.py
│   ├── dto.py
│   ├── errors.py
│   ├── main.py
│   ├── middleware.py
│   ├── services.py
│   └── settings.py: configuration and settings to run server with.
├── dev.py: runs server in developer mode
├── domain: contains the entities, values and aggregates for business domain context
│   ├── common.py
│   ├── models
│   │   ├── patient.py
│   │   └── provider.py
│   └── repository.py: Repository that abstracts away storage implementation and manages application logic between domain aggregate and data store for a specific context.
└── utils
    └── mixins.py

The GeolocationQueryService is an application service consumed by the web api route geo. See here.

The service needs to query the storage layer via a storage repository. This repository is called by the patient query look up service which is a callable and it calls the repository passing relevant parameters available in the set of: [Address, LocationQueryJSON, List[FacilitiesResult]] which are defined in dto.py.

In the repository pattern, extend IProviderStore interface in domain/models/provider.py and implement a provider store with implementation in sqlite to allow GeolocationQueryService to fetch healthcare providers in a storage -agnostic manner.

See You Wanted Banana and API First design for motivation

Goals

[ ] Understand a reproducible 'hello world' example of repository pattern
[ ] Identify parameters to consume in order to implement the repository
[ ] Identify the expected return value and edge cases for return type from repository
[x] Identify type signature and annotations for interface and sqlite implementation
[ ] Implement the Provider Repository in order to be able to return list of facilties.
[ ] Have unit test coverage
[ ] All major use cases have been identified

Expected Outcome

[ ] Unit test should be able to demonstrate a fake repository implementation using a stub storage that lives only for test session. Refer to the attached wireframe for the flow.
[ ] The repository implementation should take in the provided parameters and return either a list of care facility records or nothing.

Acceptance Criteria

[ ] The implementation repository is in repository.py under apps/ module
[ ] The interface conforms to requirements and can be tested against in the test run.
[ ] All tests including Automation tests run successfully for repository

Implementation Details

The repository’s role is to handle the persistence of aggregates.

Refer to dto.py and provider.py in order to understand the flow as described here.

The Repository receives aggregate as input parameters so first think and map the necessary DTOs to aggregate. The caller service transforms DTO to aggregates. The repository takes in and preprocesses query_id, cust_id in addition to geo location coordinates in order to call sqlite db and return a list of records, the return schema for which is defined in #12 ; The repository takes in the aggregate Provider in provider.py and performs a geo-query to filter all records that are within 50 kms of the patient's coordinates.

Query against the following tentative table attributes from the repository:

columns name	type
query_id	alphanumeric string
cust_id	alphanumeric string
lat	float
lng	float
specialty	array[text]

Expected return value For each query_id and cust_id, filter down the coordinates lat and lng and return the data. Ignore the missing attributes from the attribute column that you cannot find. Let the missing return parameters be optional while maintaining strong consistency with the JSON Type format per attribute.

Mockups/Wireframes

UML sequence for xcov19

Product Name

project-healthcare

Organisation Name

XCoV19

Domain

Healthcare

Tech Skills Needed

Database, Debugging, Flask, Python, SQL, Test, Testing Library

Mentor(s)

@codecakes

Complexity

High

Xcov19 / project-healthcare