christyjohn/vilka_mvp

This repo is a small microservice-style B2C platform split into three independently runnable Spring Boot applications: identity, marketplace (catalog), and subscription. Each service has its own pom.xml, Maven wrapper, application entry point, configuration, tests, and Flyway migrations, so they can be built and deployed separately.

The identity service is the user/account boundary. It owns authentication (AuthController, AuthService), user management (UserController, UserService), profiles, addresses, and countries. It also contains JWT support, Spring Security configuration, a custom user details service, and an internal API-key filter, which suggests it serves both public auth flows and protected internal service calls.

The marketplace service is the catalog boundary. Its only domain shown is offering, with a standard controller-service-repository-entity stack for offering lifecycle operations. It also has its own security configuration, which means it is a protected domain service rather than a public shared library.

The subscription service is the orchestration boundary. It owns subscription data and business logic, but it also depends on external services through Feign clients: MarketplaceClient and UserClient. That makes it the main integration point that validates or enriches subscription operations using catalog and identity data.

Across all three services, the internal structure is consistent: controllers expose HTTP APIs, services contain business rules, repositories handle persistence, entities map to database tables, DTOs shape request/response payloads, and mappers convert between layers. This makes the codebase easy to diagram as repeated vertical slices per bounded context.

Persistence is relational and migration-driven. Each service has src/main/resources/db/migration with versioned SQL scripts, indicating Flyway-managed schema evolution. Entities such as User, Profile, Address, Country, OfferingEntity, and Subscription are the source of truth for each service’s database model.

The main data flow in identity is: authentication requests come into AuthController, user/account state is managed through service and repository layers, and JWT-related utilities are used to secure downstream requests. The presence of InternalUserController and InternalApiKeyFilter indicates separate internal endpoints for other services to call without using the public auth flow.

The main data flow in subscription is: SubscriptionController accepts subscription requests, SubscriptionService coordinates local persistence plus remote lookups through Feign, and the service stores subscription state in its own database. This service therefore bridges local transactional state with remote dependency checks.

Security is service-local rather than centralized. Each app has its own SecurityConfig, and the subscription and marketplace services also expose SecurityUtils, likely for extracting the authenticated principal or claims from the security context. The architecture suggests JWT-based authentication established in identity and consumed by the other services.

Common platform code is repeated inside each service, not shared as a separate module. The shared patterns include ApiException, ErrorCode, ErrorResponse, GlobalExceptionHandler, and StartupTimer. These provide consistent error handling and startup instrumentation across services.

At a high level, the system boundary looks like this: identity owns who the user is, marketplace owns what can be subscribed to, and subscription owns the relationship between a user and an offering. The important cross-service dependency arrows are subscription -> identity and subscription -> marketplace; the other services do not appear to depend on each other directly.