saveliy12/microservices2

Purpose and topology

This Go workspace implements an order-processing microservice system: inventory, order, and payment services. Each service is independently buildable/containerized, while shared owns inter-service API contracts and generated bindings. Deployment is organized as service-specific Docker Compose stacks.

Service entry points

Each service starts from its own Go command and Docker image:

• Inventory: inventory/cmd/main.go, inventory/Dockerfile

• Order: order/cmd/main.go, order/Dockerfile

• Payment: payment/cmd/main.go, payment/Dockerfile

The root go.work ties the service and shared modules into one local workspace. Compose definitions reside in deploy/compose/core/docker-compose.yml and per-service directories.

Contract boundary and transport

shared is the API-contract module. Inventory and payment expose protobuf/gRPC contracts defined under shared/proto/inventory/v1/inventory.proto and shared/proto/payment/v1/payment.proto, with checked-in generated clients/server bindings in shared/pkg/proto/....

Order exposes an OpenAPI-described HTTP API: shared/api/order/v1/order.openapi.yaml, with generated server/client/router code in shared/pkg/openapi/order/v1/. Its API handlers are implemented in order/internal/api/order/v1/.

Inventory service

Inventory follows a layered request path: gRPC/API adapter → service → repository → Mongo-oriented database adapter. API operations are implemented in inventory/internal/api/inventory/v1/get.go and inventory/internal/api/inventory/v1/list.go; business operations live in inventory/internal/service/part/; persistence is in inventory/internal/repository/part/.

The database boundary is abstracted by collection interfaces in inventory/internal/client/db/collection.go, with Mongo implementation under inventory/internal/client/db/mongo/. Repository seeding is part of the inventory persistence component (inventory/internal/repository/part/seed.go).

Order orchestration and persistence

Order is the workflow-owning service. Its actions cover create, retrieve, pay, and cancel through order/internal/api/order/v1/, with orchestration and state transitions in order/internal/service/order/.

Order persists orders through repository abstractions and a PostgreSQL client: order/internal/repository/order/, order/internal/client/db/pg/client.go. Schema initialization is managed through order/internal/migrator/migrator.go and order/migrations/20260805000001_init_orders.sql.

Cross-service order flow

Order creation/payment logic calls inventory and payment through explicit outbound client adapters: order/internal/clients/inventory/inventory.go and order/internal/clients/payment/payment.go. These adapters isolate generated RPC/client protocol details from the order service layer.

The expected primary flow is: HTTP order request → API action handler → order service → PostgreSQL repository; payment-related actions additionally invoke inventory/payment clients before updating order state. Cancellation, payment, and creation are separate service commands, enabling their own validation and external-call sequencing.

Payment service

Payment is a focused gRPC service with API-to-service layering: payment/internal/api/payment/v1/pay.go delegates to payment/internal/service/payment/pay.go. It has no repository or database implementation in this tree, so payment processing is currently modeled as service-layer behavior rather than durable local persistence.

Runtime and infrastructure

Services run as Go binaries in Docker. Inventory’s persistence integration is MongoDB-oriented; Order’s is PostgreSQL-oriented. The order service is the only service with explicit synchronous dependencies on the other two. Service topology and backing dependencies are provisioned through deploy/compose/inventory/docker-compose.yml, deploy/compose/order/docker-compose.yml, and deploy/compose/payment/docker-compose.yml.