miw-upm/goa

1. What this repository is

- This is not the application source code itself. It is a support repository for a teaching example of the GOA legal-office platform.

- Its main purpose is to document architecture and provide deployment/database configuration artifacts for the broader system.

2. System being described

- The target system is a law-firm management application split into:

- an Angular front-end

- a microservices back-end

- The README explicitly says the back-end uses both 3-layer and hexagonal architectural styles, so different services may be structured differently but share the same overall platform.

3. Main runtime subsystems

- The back-end is composed of several independently deployed services:

- GOA User

- GOA Engagement

- GOA Billing

- GOA Document

- GOA Support

- GOA AI1 / GOA AI2

- Supporting infrastructure services include:

- GOA Gateway

- GOA Eureka

- The gateway acts as the public entry point, while Eureka provides service discovery for the microservices.

4. Request flow

- Typical traffic path is:

- browser/client → Angular front-end

- front-end → Gateway

- gateway → targeted microservice

- microservice → its database

- Service-to-service resolution is likely handled through Eureka, which fits the microservice discovery model described in the README.

5. Security boundary

- Security is based on OAuth2 and OpenID Connect.

- The README indicates both authentication flows are implemented in the API, so the back-end is not just a resource server; it also participates in identity-related responsibilities.

- This means the authentication/authorization boundary sits at the API layer rather than in the front-end.

6. Persistence layer

- Persistence uses JPA with Hibernate on top of PostgreSQL.

- The database/docker-compose-db.yml file suggests local database provisioning is containerized for development/testing.

- The architecture is therefore database-backed rather than event-driven or file-based.

7. Deployment and ingress

- The deploy/ directory shows the operational edge of the system:

- nginx-conf-miwupm.txt

- nginx-conf-ocanabogados.txt

- cd-update-nginx-config.yml

- This indicates Nginx is used as the reverse proxy / public ingress layer, with different configs for different environments or hostnames.

- deploy/instance-lightsail.md shows the system is deployed on AWS Lightsail in at least one setup.

8. Environment-specific concerns

- The presence of separate Nginx configs for miwupm and ocanabogados implies this repo supports multiple deployment targets or branding variants.

- The README’s AWS badges and system version endpoints suggest the services expose health/version endpoints used for operational visibility.

9. Operational/teaching focus

- The repo is clearly educational: it supports MDW/BETCA coursework and demonstrates microservices, layered/hexagonal design, persistence, and OAuth2/OIDC in one example.

- The architecture file architecture/rest-project-duplicate.md likely captures the design rationale for one of the REST service patterns used in the system.

10. What to draw in an architecture diagram

- Show the browser on the left, the Angular front-end, then Nginx/Gateway as the public entry path.

- Behind that, show the microservices as separate bounded contexts, each with its own PostgreSQL-backed persistence.

- Add Eureka as the discovery/control-plane service and OAuth2/OIDC as the authentication authority/integration point.

- Place the database/ and deploy/ artifacts as supporting infrastructure around the runtime system, not as application components themselves.