Loosely inspired by the organization of [WTFDial](https://github.com/benbjohnson/wtf?tab=readme-ov-file#project-structure),
- Application domain types reside in the project root (User, UserService, etc)
- Implementations of the application domain reside in the subpackages `sqlite`, `http`, etc.
- Everything is tied together in the `cmd` subpackages
### Application Domain
This is project is an Indie reader inspired by [Feedi](https://github.com/facundoolano/feedi).
### Implementation Subpackages
The subpackages function as an adapter between our domain and the technology used to implement the domain. For example `sqlite.FeedService` implements the `ratchet.FeedService` using SQLite.
Subpackages ideally **SHOULD NOT** know about one another and **SHOULD** communicate in terms of the application domain.
A special `mock` packages can be used to create simple mocks for each application domain interface. This will allow each subpackages unit tests to share a common set of mocks so layers can be tested in isolatation.
### Binary Packages
With loosely coupledc subpackages the application is wired together in the `cmd` subpackages to produce a final binary.
The `cmd` packages are ultimately the interface between the application domain and the operator. Configuration of types and any CLI flags *SHOULD* live in these packages.
## Development
You can build `ratchet` locally by cloning the respository, then run
`make`
`go install ./cmd/...`
The `ratchetd` cmd binary uses Oauth so you will need to create a new Oauth App. The vlaue of the authorization callback must be the hostname and IP at which clients can access the `ratchetd` server.
