How thunyaponle/agnos works
Purpose and Runtime
This repository contains Agnos/hospital-middleware, a Go HTTP middleware/API service for hospital staff and patient operations. The documented addition is POST /api/patient/create, which persists a new patient record. It runs as a containerized service, with PostgreSQL and Nginx deployment/proxy artifacts in Agnos/hospital-middleware/docker-compose.yml, Agnos/hospital-middleware/Dockerfile, and Agnos/hospital-middleware/nginx.conf.
Application Entry and Composition
Agnos/hospital-middleware/cmd/server/main.go is the executable entry point. It is responsible for assembling configuration, database access, repositories, services, controllers, and HTTP routes. Configuration is centralized in Agnos/hospital-middleware/config/config.go; PostgreSQL connection setup is in Agnos/hospital-middleware/database/postgres.go.
HTTP Routing and Access Boundary
Agnos/hospital-middleware/routes/routes.go defines the public API surface and connects endpoints to controllers. Agnos/hospital-middleware/middleware/auth.go is the authentication boundary for protected requests, while Agnos/hospital-middleware/service/jwt.go provides JWT-related behavior. Requests should pass routing/authentication before reaching domain handlers.
Controller Layer
HTTP request parsing, response construction, and delegation are separated into patient and staff controllers:
• Agnos/hospital-middleware/controller/patient_controller.go
• Agnos/hospital-middleware/controller/staff_controller.go
The patient controller owns the create-patient endpoint path’s transport concerns; it delegates business work rather than directly owning SQL access.
Domain Services
Service classes contain the application-level patient and staff workflows:
• Agnos/hospital-middleware/service/patient_service.go
• Agnos/hospital-middleware/service/staff_service.go
They operate on domain models in Agnos/hospital-middleware/model/patient.go, Agnos/hospital-middleware/model/staff.go, and Agnos/hospital-middleware/model/hospital.go. JWT support is a cross-cutting service dependency rather than a persistence concern.
Persistence Boundary
Repository interfaces separate services from concrete storage:
• Agnos/hospital-middleware/repository/patient_repository.go
• Agnos/hospital-middleware/repository/staff_repository.go
• Agnos/hospital-middleware/repository/hospital_repository.go
PostgreSQL implementations live in Agnos/hospital-middleware/repository/patient_postgres.go, Agnos/hospital-middleware/repository/staff_postgres.go, and Agnos/hospital-middleware/repository/hospital_postgres.go. Schema initialization is represented by Agnos/hospital-middleware/migrations/001_init.sql. Mock repositories allow service logic to be substituted away from PostgreSQL.
Primary Flows
For patient creation, control flows: route → auth middleware when applicable → patient controller → patient service → patient repository interface → PostgreSQL repository → database. The response returns through the controller. Staff flows follow the equivalent controller/service/repository chain. A distinct outbound integration client, Agnos/hospital-middleware/client/hospital_a_client.go, forms a boundary to an external Hospital A service; its calls should remain isolated from HTTP handlers and database repositories.
Main entry points: main.go Server composition · patient_service.go Patient service · routes.go API routes · staff_service.go Staff service
Components 20
Runtime & Deployment
- Container deployment · Runs the service with PostgreSQL and Nginx.
Agnos/hospital-middleware/docker-compose.yml - Nginx proxy
Agnos/hospital-middleware/nginx.conf - Server composition · Wires configuration, database, repositories, services, controllers, and routes.
Agnos/hospital-middleware/cmd/server/main.go - Configuration
Agnos/hospital-middleware/config/config.go
HTTP API
- API routes · Defines public endpoints including POST /api/patient/create.
Agnos/hospital-middleware/routes/routes.go - Auth middleware · Protects applicable requests before handlers.
Agnos/hospital-middleware/middleware/auth.go - Patient controller · Handles patient request parsing and responses.
Agnos/hospital-middleware/controller/patient_controller.go - Staff controller
Agnos/hospital-middleware/controller/staff_controller.go
Application Layers
- JWT service
Agnos/hospital-middleware/service/jwt.go - Patient service · Owns patient workflows including creation.
Agnos/hospital-middleware/service/patient_service.go - Staff service
Agnos/hospital-middleware/service/staff_service.go - Hospital domain models · Patient, staff, and hospital entities.
Agnos/hospital-middleware/model/patient.go - Hospital A client · Isolates outbound Hospital A calls.
Agnos/hospital-middleware/client/hospital_a_client.go
Persistence
- Patient repository
Agnos/hospital-middleware/repository/patient_repository.go - Staff repository
Agnos/hospital-middleware/repository/staff_repository.go - Hospital repository
Agnos/hospital-middleware/repository/hospital_repository.go - PostgreSQL repositories · Concrete patient, staff, and hospital persistence.
Agnos/hospital-middleware/repository/patient_postgres.go - PostgreSQL connection
Agnos/hospital-middleware/database/postgres.go - PostgreSQL
- Initial schema
Agnos/hospital-middleware/migrations/001_init.sql
Connections 26
- Container deployment → Nginx proxy: runs
- Container deployment → Server composition: runs
- Container deployment → PostgreSQL: runs
- Nginx proxy → API routes: proxies requests
- Server composition → Configuration: loads
- Server composition → PostgreSQL connection: initializes
- Server composition → API routes: registers
- Server composition → Patient service: wires
- Server composition → Staff service: wires
- API routes → Auth middleware: protects requests
- Auth middleware → JWT service: validates tokens
- Auth middleware → Patient controller: authorizes
- API routes → Staff controller: dispatches
- Patient controller → Patient service: delegates create patient
- Staff controller → Staff service: delegates
- Patient service → Patient repository: uses
- Staff service → Staff repository: uses
- Patient service → Hospital domain models: operates on
- Staff service → Hospital domain models: operates on
- Patient service → Hospital A client: calls when needed
- Patient repository → PostgreSQL repositories: implemented by
- Staff repository → PostgreSQL repositories: implemented by
- Hospital repository → PostgreSQL repositories: implemented by
- PostgreSQL repositories → PostgreSQL connection: uses connection
- PostgreSQL connection → PostgreSQL: connects
- Initial schema → PostgreSQL: initializes schema