[ project / platform ]
In-house publishing back-office platform
Book Publishing Platform
Book Publishing Platform is an API-first back-office system for managing a publisher's catalog, designed and delivered end to end from domain modelling and persistence to a secured Android client and cloud deployment.
01 / product
From publishing workflow to working software
Editorial Denes needed an internal catalog-management workflow that could keep books, authors, and collections in one dependable place. Book Publishing Platform centralizes that work as an in-house back-office system used in production, rather than treating each repository as a separate product.
The work spans the complete delivery path: understanding the requirements, modelling the publishing domain, designing the API, implementing persistence and security, integrating the client, testing the boundaries, and deploying the resulting service to the cloud.
Granular access to the platform
The platform implements JWT-based authentication and role- and permission-based authorization, providing granular control over access to the service and the actions each user can perform. These rules are enforced by the backend and remain independent from the current Android client.
02 / architecture
One platform, clear system boundaries
OpenAPI contract
A versioned repository defines the public boundary independently from any one client or implementation.
Backend service
Kotlin and Spring Boot keep the domain, use cases, adapters, security, and persistence concerns explicit.
Administrative client
A native Android app consumes the secured API for day-to-day catalog management; it is one client of the platform.
Persistent catalog
PostgreSQL stores the publishing domain, with Liquibase making schema evolution repeatable and reviewable.
03 / backend
Keeping the domain at the center
Kotlin and Spring Boot
A pragmatic service foundation for the API, application use cases, and integration with the platform boundary.
Domain-Driven Design
The model follows the publishing problem and keeps business rules meaningful outside the transport layer.
Vertical slices
Business contexts keep domain, application, and infrastructure responsibilities close without collapsing their boundaries.
Hexagonal architecture
Ports and adapters isolate the domain from HTTP, persistence, frameworks, and other delivery mechanisms.
Persistence and security
PostgreSQL, Liquibase, JWT authentication, and server-side role checks protect and evolve the platform safely.
04 / api-first
Treating the contract as a product boundary
The OpenAPI specification lives in its own versioned repository and acts as the source of truth for the API. It generates Kotlin interfaces and DTOs consumed by the backend, keeping the contract and implementation aligned.
Define the boundary
Endpoints, payloads, validation, and error shapes are maintained in the versioned OpenAPI specification.
Generate the shared types
Kotlin interfaces and DTOs turn the reviewed contract into an implementation-facing artifact.
Implement behind the boundary
The Spring Boot backend consumes the generated artifact, keeping transport changes explicit and reviewable.
05 / quality
Confidence through boundaries, tests, and automation
Domain boundaries
Isolated domain and use-case tests exercise business rules without requiring the web or database layers.
HTTP boundaries
Mapper and controller tests cover serialization, validation, security, and response behavior through Spring and MockMvc.
Production-shaped integration
PostgreSQL integration tests use Testcontainers, while higher-level API and integration validation checks the assembled system.
Android confidence
The client is tested at the ViewModel, repository, and Compose UI boundaries rather than only through manual checks.
Automated delivery gates
Pull-request and CI/CD validation provide repeatable checks before changes are integrated and deployed.
06 / methodology
From product intent to production
Define measurable objectives
Project goals are translated into measurable OKRs and KPIs so delivery progress and engineering outcomes remain visible.
Plan the work
A GitHub Project makes priorities, status, stages, and delivery context visible across the platform.
Refine the product scope
Milestones turn the product outcome into requirements, success criteria, delivery stages, and explicit exclusions.
Break down technical delivery
Dependency-ordered issues describe one observable outcome at a time and keep backend, contract, client, and infrastructure work aligned.
Implement and validate
Focused branches carry the implementation, tests, and automated checks while unrelated work remains separate.
Review, integrate, and deploy
Pull-request review and CI/CD validation provide the delivery gate before the Dockerized service reaches Cloud Run.
07 / evolution
A platform that can take on new workflows
Public publisher website
A web client is already in progress and can consume the same API without moving publishing rules into a frontend.
Inventory management
The backend can grow into stock and inventory workflows while keeping the publishing domain and access rules explicit.
More platform consumers
Additional clients and integrations can adopt the versioned contract without creating a separate product boundary.
Book Publishing Platform is one end-to-end engineering story: a production back office whose domain, API boundary, client, and delivery path are designed to evolve together.