EBYS/DYS Platform

Project Type and Current Status

• The project is a full-stack enterprise web application that combines electronic document management, document lifecycle operations, workflow management, organization-scoped authorization, auditing, and reporting.
• I developed it as a personal engineering project to model the technical and operational requirements of a real institutional EBYS/DMS platform.
• The project is still under active development and is currently published in the UAT environment. The first 34 sprints have been completed, and the next sprints are currently being planned.

Motivation and Scope

• I wanted to move beyond a simple CRUD example and build a system in which document ownership, organization hierarchy, role and permission boundaries, workflow decisions, registry numbering, auditability, and deployment operations work together.
• The delivered scope includes document upload and multiple upload, versioning, download, PDF preview, incoming and outgoing registry flows, reviewer assignment, assigned work and unit pools, supervision, organization management, audit history, dashboard summaries, reports, exports, and CSV-based administrative imports.
• Future roadmap items such as configurable workflow definitions, e-signature, archive and retention, advanced search, OCR, AI-assisted classification, and multi-tenant preparation are documented separately and are not presented as completed features.

Current UAT Dataset

• The 30 July 2026 UAT dataset contains 10,009 users, 6 roles, 34 permissions, 83 organization assignments, 901 organization units, and 2,691 positions.
• Document administration contains 563 categories and 235 registry books.
• These figures describe the current UAT dataset and may grow as development, imports, identity reconciliation, and simulation scenarios continue.

Architecture / System Design

• The backend follows a layered, domain-oriented structure with API, Application, Domain, Persistence, Infrastructure, Shared, Gateway, and Worker projects.
• ASP.NET Core Minimal API exposes use cases; the Application layer executes business rules; Domain protects entity behavior; Entity Framework Core and SQL Server handle persistence and migrations.
• The Angular 21 frontend uses reusable components, reactive forms, centralized API error handling, route and permission guards, and consistent PrimeNG, PrimeFlex, and Tailwind CSS patterns.
• Authentication is delegated to Keycloak. Application roles, fine-grained permissions, organization assignments, and scope rules are evaluated by backend authorization policies rather than relying on menu visibility.
• Files and generated previews are stored in MinIO. Gotenberg/LibreOffice performs document-to-PDF conversion, while Hangfire and the separate Worker host execute long-running operations outside the request flow.
• YARP Gateway provides a stable external API boundary; Redis supports caching, SignalR provides realtime updates, and Serilog + Seq provide structured, correlation-aware operational logs.

Background Jobs, Realtime Updates, and Observability

• Hangfire runs only inside the dedicated Worker service. It owns background queues, recurring schedules, retries, execution state, and operational dashboard visibility without turning the API process into a job server.
• Document preview jobs convert supported Office files to PDF through Gotenberg/LibreOffice, store the generated artifacts in MinIO, and keep uploads responsive by completing conversion outside the HTTP request.
• The recurring workflow.simulation.continuous-activity job creates controlled document, registry, and workflow activity in non-production environments through the real authenticated API. It is used to exercise authorization, organization scope, audit, and recovery behavior.
• The simulator continuously executes configured scenarios such as document uploads and versions, responsibility changes, review submission and assignment, approve/reject/return decisions, unit dispatch, ownership, and incoming/outgoing registry operations.
• This keeps the UAT system under continuous workload and continuously produces dashboard, audit, preview, Hangfire, SignalR, and Seq data even without manual interaction. The activity is controlled synthetic UAT traffic, not production-user traffic.
• The recurring identity.reconciliation.sync-users job synchronizes and reconciles identity records between Keycloak and the application.
• SignalR publishes a lightweight dashboard-change notification after successful operations. The frontend debounces the event and refetches the authorized dashboard summary; document or dashboard payloads are not carried through SignalR.
• Seq centralizes structured Serilog events. Correlation IDs and job, run, scenario, step, action, conversion, and document identifiers make API, Worker, preview conversion, and workflow failures traceable without logging passwords, tokens, or document content.

Tools: What I Used and Why

• SRS and repository documentation: I started with a Software Requirements Specification, then kept architecture decisions, sprint plans, QA evidence, deployment instructions, and operations notes close to the code.
• Taiga: I divided the roadmap into epics, user stories, tasks, and sprints. Repository scripts synchronize sprint markdown files with Taiga using dry-run and apply steps.
• Git and Forgejo: Each story receives a coded branch and conventional commit history, then moves through a pull request and merge flow. This preserves traceability from requirement to implementation.
• OpenAI Codex: I used it as an engineering assistant for requirement decomposition, implementation and refactoring support, architecture and security reviews, test analysis, documentation consistency, and deployment automation. I retained responsibility for scope, technical decisions, review, and validation.
• Docker Compose: I used containers to reproduce the UAT topology, including frontend, gateway, API, Worker, converter, Seq, and infrastructure dependencies.
• Infisical, Cloudflare, and Nginx Proxy Manager: Infisical is the source of shared environment secrets; Cloudflare and Nginx Proxy Manager provide DNS, edge routing, reverse proxy, and TLS boundaries.
• Scalar OpenAPI, xUnit, Vitest, ESLint, and Prettier: I used these tools for API discovery, backend unit/integration/architecture tests, frontend tests, static checks, and consistent formatting.
• Forgejo Actions CI/CD: Pull requests and merges run changed-area detection, backend build and architecture tests, EF Core model checks, backend unit and integration tests, frontend quality and unit tests, production builds, Docker image builds, and UAT deployment steps.

Live Addresses and Demo Access

• UAT application: https://ebys-uat.erengaygusuz.com.tr
• Project management / Taiga: https://taiga.erengaygusuz.com.tr/project/ebysdys-document-workflow-management-platform/timeline
• Git provider, pull requests, and CI/CD / Forgejo: https://forgejo.erengaygusuz.com.tr/eren-enterprise-lab/ebys-dys-platform

Main Modules and Technical Highlights

• Document management: upload, multiple upload, versions, download, responsibility and ownership, PDF preview, asynchronous conversion, and visibility policies.
• Workflow: submit for review, reviewer assignment, assigned-to-me queue, unit pool, take ownership, approve/reject/return decisions, reassignment, supervision, and unit-to-unit dispatch.
• Identity and organization: users, enterprise role presets, permissions, organization units, positions, user assignments, manager flags, and own-unit/child-unit/all-unit scopes.
• Registry and administration: categories, registry books, incoming and outgoing numbering, and CSV imports for high-volume administrative data.
• Audit and reporting: application activity history, document audit visibility, dashboard summaries, realtime updates, workflow reports, and CSV/XLSX/PDF exports.

Development Method and Traceability

• I followed the chain SRS → roadmap → sprint → Taiga story → branch → pull request → QA evidence → UAT deployment.
• Story codes such as DOC, WFL, IAM, ORG, RPT, INFRA, and QA appear consistently in sprint files, branches, commits, and pull requests.
• As of the snapshot, the repository contains 600 commits, 212 merged pull requests, and 33 completed sprints. This made the work measurable without treating planned roadmap items as delivered.

Participation and Development Time

• I developed the project independently as software architect, full-stack developer, test owner, and DevOps owner.
• According to Git history, development began on 22 June 2026. The first documented UAT milestone was reached on 25 July 2026 in 34 calendar days, or approximately five weeks, when both boundary dates are counted.
• Development is still continuing. I handle requirements, architecture, domain modeling, backend and frontend implementation, database migrations, automated tests, documentation, containerization, CI/CD, and UAT operations.

Quality and Validation

• The 24 July 2026 automated baseline passed with 0 build warnings and 0 errors, 8/8 architecture tests, 856/856 backend unit tests, 259/259 integration tests, and 56/56 frontend tests.
• The same quality gate checked EF Core model/migration drift, frontend formatting and linting, the production build, skipped-test markers, temporary TODO/FIXME exceptions, and repository whitespace.
• The project also keeps sprint-specific manual QA scenarios and UAT smoke matrices. With Sprint 34 completed, the QA scope for the upcoming sprints is being planned alongside the next development cycle.

Deployment and Operations

• The project is currently published in the UAT environment. Docker Compose separates the frontend, gateway, API, Worker, converter, logging, and dependency services.
• Runtime secrets and environment configuration are supplied through Infisical as the central source of truth. Environment-specific API, Worker, Gateway, Keycloak, SQL Server, Redis, MinIO, Hangfire, and converter settings are injected during deployment instead of being committed to the repository.
• Public traffic is designed to pass through Cloudflare and Nginx Proxy Manager before reaching internal Docker services. Seq is used to inspect structured logs and correlation data.
• The Forgejo Actions pipeline validates code and migrations, runs automated tests, builds application images, and deploys the accepted UAT candidate. The project remains a UAT system and is not presented as a production release.