This service manages user onboarding process.
The project implements the
Clean Architecture advocated by
Robert Martin ('Uncle Bob').
A cleanly architected project should be:
Independent of Frameworks: The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
Testable: The business rules can be tested without the UI, Database, Web Server, or any other external element.
Independent of UI: The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
Independent of Database: You can swap out Cloud Firestore or SQL Server, for Mongo, Postgres, MySQL, or something else. Your business rules are not bound to the database.
Independent of any external agency: In fact your business rules simply don’t know anything at all about the outside world.
This project has 5 layers:
Here we have
business objects or
entities and should represent and
encapsulate the fundamental business rules.
In the domain layer we should have no idea about any database nor any storage, so the repository is just an interface.
These are the
ports that allow the system to talk to 'outside things' which
could be a
database for persistence or a
web server for the UI. None of
the inner use cases or domain entities should know about the implementation of
these layers and they may change over time because ... well, we used to store
data in SQL, then document database and changing the storage should not change
the application or any of the business rules.
The code in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.
This represents the pure business logic of the application. The rules of the application also shouldn't rely on the UI or the persistence frameworks being used.
This represents logic that consume the business logic from the
and renders to the view. Here you can choose to render the view in e.g
Points to note
- Interfaces let Go programmers describe what their package provides–not how it does it. This is all just another way of saying “decoupling”, which is indeed the goal, because software that is loosely coupled is software that is easier to change.
- Design your public API/ports to keep secrets(Hide implementation details) abstract information that you present so that you can change your implementation behind your public API without changing the contract of exchanging information with other services.
For more information, see:
- The Clean Architecture advocated by Robert Martin ('Uncle Bob')
- Ports & Adapters or Hexagonal Architecture by Alistair Cockburn
- Onion Architecture by Jeffrey Palermo
- Implementing Domain-Driven Design
For local development, you need to export the following env vars:
# Google Cloud Settings export GOOGLE_APPLICATION_CREDENTIALS="<a path to a Google service account JSON file>" export GOOGLE_CLOUD_PROJECT="<the name of the project that the service account above belongs to>" export FIREBASE_WEB_API_KEY="<an API key from the Firebase console for the project mentioned above>" # Go private modules export GOPRIVATE="gitlab.slade360emr.com/go/*,gitlab.slade360emr.com/optimalhealth/*" export REPOSITORY="firebase" # when we switch to PG the value will be `postgres` # Charge Master API settings export CHARGE_MASTER_API_HOST="<a charge master API host>" export CHARGE_MASTER_API_SCHEME=https export CHARGE_MASTER_TOKEN_URL="<an auth server token URL>" export CHARGE_MASTER_CLIENT_ID="<an auth server client ID>" export CHARGE_MASTER_CLIENT_SECRET="<an auth server client secret>" export CHARGE_MASTER_USERNAME="<an auth server username>" export CHARGE_MASTER_PASSWORD="<an auth server password>" export CHARGE_MASTER_GRANT_TYPE="<an auth server grant type>"
This application is deployed via Google Cloud Build ( https://cloud.google.com/build ) to Google Cloud Run ( https://cloud.google.com/run ).
cloudbuild.yaml file in the home folder. Secrets (e.g production settings) are managed with Google Secret Manager ( https://cloud.google.com/secret-manager ).
There is no documentation for this package.
Package interactor represent reusable chunks of code that abstract logic from presenters while simplifying your app and making future changes effortless.
|Package interactor represent reusable chunks of code that abstract logic from presenters while simplifying your app and making future changes effortless.|