- GET “/properties”
- GET “/properties/:id”
- POST “/properties”
- PUT “/properties/:id”
- POST “/manager”
- GET “/apartments”
- GET “/apartments/:id”
- POST “/apartments”
- PUT “/apartments/:id”
- GET “/tenants”
- GET “/tenants/:id”
- POST “/tenants”
- PUT “/tenants/:id”
- GET “/payments”
- GET “/payments/:id”
- GET “/tenant/:id/payments”
- clone repository
- change into project directory
go generate ./entto generate the models
go mod tidyto tidy
- RRun application with
go run main.go
- Run tests with
go test ./...or specific package tests with
go test ./property -v
The following needs to be installed to run application
- install sqlite3 on system, it is needed by dependency
github.com/mattn/go-sqlite3(OR OPTIONAL mysql
go get github.com/go-sql-driver/mysql)
Following the Clean Architecture by Uncle Bob
- 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 Oracle or SQL Server, for Mongo, BigTable, CouchDB, 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 4 Domain layer :
- Domain Layer
- Repository(DB) Layer
- Usecase(Service) Layer
- Handler(Controller) Layer
- Installed Mockery with
brew install mockery
mockery --all --inpackageto generate mocks for repo and service
- To run all tests with
go test ./...
- To run specific test with package name, example
go test ./property -v
- Payment GET API has
to_datewhich can query with a historical period
- Payment entity has state
unprocessedwhich maybe updated to indicate payment processing (if applicable)
- Payment entity has a mapping to Apartment entity with
owner_idand Apartment entity has a mapping Property entity so one can query
Get Property -> Apartments -> Payments
- To extend service to get history payments for property, we can build another Payment GET API
/property/:id/paymentswhich takes in query params
to_date. In the repo this would make join query to fetch the Apartments for the property
id, and get the Payments for each Apartment with the dates sent.