A high-performance, real-time chess ecosystem engineered with a focus on Domain-Driven Design (DDD), Clean Architecture, and Enterprise-Grade Infrastructure.
Operational Status: The core chess engine is 100% operational, strictly adhering to FIDE rules.
Latest Milestone: Successfully completed Phase 11, implementing the LGTM (Loki, Grafana, Tempo, Prometheus) Stack. The system now features real-time performance monitoring, centralized logging, and distributed tracing, providing deep visibility into the system's internal state through OpenTelemetry.
This project is architected as a high-cohesion monorepo. Operational processes and architectural decisions are managed through the following modules:
| Module / Document | Purpose & Brief | Location |
|---|---|---|
| βοΈ Backend | Core Chess Engine, API endpoints & Move validation logic | ./chess-backend |
| π¨ Frontend | Reactive UI components & Real-time board state management | ./chess-frontend |
| ποΈ Architecture | High-level design choices (Hexagonal, DDD) & Tech patterns | ./docs/ARCHITECTURE.md |
| π Setup Guide | Comprehensive local environment & Dependency installation | ./docs/DEVELOPMENT.md |
| π Git Flow | Contribution workflow, Branching strategy & Commit standards | ./.github/GIT_GUIDE.md |
| π Changelog | Daily Evolution, version tracking & project milestones | ./docs/CHANGELOG.md |
| π‘οΈ Security | Security policies, safety disclosure & best practices | ./docs/SECURITY.md |
| π€ Contributing | Coding standards, PR guidelines & collaboration rules | ./docs/CONTRIBUTING.md |
- The Challenge: Relying on Hibernate's
ddl-auto: updatein a containerized environment is risky. Schema changes must be traceable, reversible, and consistent across all environments. - The Solution: Integrated Liquibase to manage database migrations through versioned SQL changelogs.
- The Result: Professional, auditable database evolution. Guaranteed 1:1 schema parity between local development and Dockerized production environments.
- The Challenge: In Docker Compose, services starting simultaneously can lead to "Connection Refused" errors if the backend tries to connect before the DB or Redis is ready.
- The Solution: Implemented custom Docker Health-Checks and
depends_on: service_healthyconditions. - The Result: The backend initializes only after PostgreSQL and Redis are fully "Healthy," ensuring a resilient, zero-fail deployment flow.
- The Challenge: Validating King safety (check detection) requires executing a move. This poses a risk of corrupting the live game state during the validation process.
- The Solution: Developed a Simulation & Rollback mechanism using Java Records. The engine clones the state, simulates the move on a virtual board, and discards it after safety verification.
- The Result: 100% side-effect-free move validation, ensuring total state integrity.
The core chess logic is encapsulated in a Pure Java domain layer.
- Zero Infrastructure Leakage: Move validation is entirely decoupled from Spring Boot, ensuring 100% unit testability.
- Polymorphic Validation: Each piece (
Rook,Bishop, etc.) encapsulates its own logic, eliminating high-cyclomatic complexity fromswitch-caseblocks.
- FIDE Compliance: Full support for Castling, En Passant, and Pawn Promotion.
- King Safety Simulation: Dry-run execution to detect Check, Checkmate, and Stalemate.
- Efficient Pathfinding: Optimized vector-based collision detection for sliding pieces to maintain high engine throughput.
- Modern React (v19): Utilizing custom hooks and Tailwind CSS for a high-performance, responsive Board UI.
- Lobby & Social: Sophisticated Lobby System and persistent User Statistics against players or the Training Bot.
Current Status: π Phase 12: Quality Assurance & Code Integrity
- β Phase 1: Foundation ποΈ - Monorepo scaffolding, environment setup, and Spring Boot/React initialization.
- β Phase 2: Domain Modeling βοΈ - Piece-specific logic, board initialization, and DDD-based movement rules.
- β Phase 3: Rule Engine βοΈ - Legal move validation (King safety, check/mate detection) and FIDE standards.
- β Phase 4: Communication Layer π‘ - WebSocket infrastructure using STOMP protocol and real-time event mapping.
- β Phase 5: UI Integration & Local Play π₯οΈ - Interactive React 19 board, Pawn Promotion, and Castling UI.
- β
Phase 6: Visual Polish & UX π¨ - Dark/Light mode, theme support (Classic, Modern, Emerald), and Drag & Drop (
dnd-kit). - β Phase 7: Identity & Persistence π - Implemented Spring Security + JWT, User profiles, and PostgreSQL integration.
- β Phase 8: Server-Side Authority π‘οΈ - Hardened backend validation for all moves and anti-cheat state management.
- β Phase 9: Remote Multiplayer & Matchmaking π€ - Global session management and real-time player pairing via WebSockets.
- β Phase 10: Infrastructure & Containerization π³ - Orchestrating services with Docker & Docker Compose and implementing Liquibase for DB versioning.
- β Phase 11: Full-Stack Observability (LGTM) π - Implementing Grafana, Loki, and Prometheus for real-time logs, metrics, and system health.
- β³ Phase 12: Quality Assurance & Code Integrity π - Expanding JUnit 5/Mockito coverage and integrating SonarQube for automated "Zero Technical Debt" reporting.
- π Phase 13: Scalability & Resilience β‘ - Implementing Resilience4j (Circuit Breaker) and Distributed Locking with Redis.
- π Phase 14: Messaging & Async Logic βοΈ - Integration of RabbitMQ/Kafka for background processing, notifications, and analytics.
- π Phase 15: Advanced Analytics & AI π§ - Integration of Stockfish via UCI protocol for move analysis and "Hint" system.
The entire application ecosystem is managed using Docker Compose to ensure absolute consistency between development and production environments.
Infrastructure Note: All services (PostgreSQL, Redis, Spring Boot, and React) include health-check protocols to ensure reliable inter-service communication and deterministic container startup sequences.
Batuhan Baysal - Software Engineer Scalable Software Design, Modern Java, and Backend Architectures.

