This library powers the onboarding service.
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.
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 Usecase Layer
and renders to the view. Here you can choose to render the view in e.g
graphql or rest
- 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