Java architecture for enterprise platforms
Spring Boot services that stay modular, testable and operable under real traffic. By Sanjeev Kumar, Application Architect.
Module boundaries before frameworks
Most Java platforms I work on use Spring Boot, but the durable decisions are about package and module boundaries: domain cores that do not import web or messaging adapters, explicit application services, and infrastructure at the edges. Hexagonal / clean layouts make strangler-fig migrations feasible — as in the financial platform case study — because new services can own a vertical without rewriting the world on day one.
API-first contracts
Versioned REST (and gRPC where fan-out latency demands it), published OpenAPI, and backward-compatible evolution beat “just ship the DTO”. Gateways enforce authn/authz; services enforce domain invariants. Idempotency keys on money-moving and other side-effecting commands are non-negotiable in banking and insurance paths.
Data, transactions and messaging
Keep transactional boundaries small. When a write must fan out, prefer transactional outbox into Kafka / event-driven pipelines over dual-writes. JPA/Hibernate stays productive when aggregate roots are clear; fight the urge to lazy-load half the graph inside a web request. The same Spring Boot services can host retrieval and LLM gateway clients when enterprise AI features sit beside core domain APIs.
Production readiness
Structured logging, metrics, tracing, health probes, circuit breakers and bulkheads are part of the architecture. Container images stay lean; config is externalised; secrets never ride in the repo. Pair with cloud and microservices notes for the platform view.