-
Notifications
You must be signed in to change notification settings - Fork 0
Application Architecture
The design of the application tries to follow some of the best practices, with some modifications to make it more practical. Here are some of the resources that guided the design.
- https://12factor.net/
- https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
- https://airbrake.io/blog/software-design/domain-driven-design
- https://restfulapi.net/rest-architectural-constraints/
This is where the application is glued together. It loads the config, creates all objects, and resolves all dependencies in order to run the application. This is generally where you would integrate a new part of the application to be exposed.
This folder holds all of the commands that our application can run, here it is just a command to start the server.
This holds our configuration files, we are using JSON to hold our config values. Anything added to the JSON file will be available in app.go
This is the entities that encompass our entire application, these models are generally very barebones containing only model definitions and some utility functions for the model such as printing to a string, validating the model, etc.
This is the persistence layer for our application. We currently also namespace the type of store that is being used ie postgres, elasticsearch, redis, etc. This allows us to abstract away the way to save a model without worrying about how it is getting stored. This should ideally only rely on the model alone and nothing to do with the rest of the application as it should focus on just persistence.
This handles all of the use cases that our application does. We separate this layer our so that no matter how we expose the application, it always has the same use cases and will produce the same result without having to duplicate the same use cases. This should generally rely on the model and some stores for the persistence layer. It may also use utils
This handles how are application expose itself to the outside world. It currently only exposes http endpoints through REST resources, but could very easily expose something like a graphql or grpc endpoint by adding more adapters. The adapters generally rely on services to implement the use cases.
This is mocks for the application such as a logger mock, db mock, etc. These generally make testing easier as we do not have to rely on some impure external item when doing unit testing, because we can ensure consistent results.
This is where items that are not generally part of any particular part live, such as a random id generator or a JWT generator.