Java Backend Systems

Backend learning becomes more useful when domain rules, persistence, transport, validation, and security are separated instead of accumulated in controllers.

The systems remain educational and repository-verifiable. They do not claim production traffic, deployed scale, or business outcomes.

Both projects use layered Spring Boot boundaries. The commerce API covers catalog, cart, order, and payment domains; RideShare covers identity, role authorization, booking, and ride lifecycle state.

DTO validation, custom exceptions, structured errors, and service-owned business rules keep transport and domain responsibilities distinct.

The commerce system includes a mock payment gateway and webhook-style asynchronous confirmation. RideShare models requested → accepted → in-progress → completed with authenticated and authorized roles.

RideShare uses Spring Security, JWT, and RBAC. Both systems use validation, global error handling, and layered boundaries that keep failure behavior more predictable.

Service logic is structured to be testable. Exact test coverage remains documented by each repository rather than summarized with invented metrics.

Together, the projects document a deeper move from building endpoints to designing domain boundaries and security rules.

Payment behavior is mocked, persistence and deployment choices are educational, and neither repository is presented as a production service.

A clear backend is easier to reason about when each layer has a small and enforceable job.