kalintsenkov/BettingSystem

This system is a sports betting and competition management platform that allows users to register, manage profiles, and place bets on matches. It provides comprehensive management of sports data, including leagues, teams, and match states, while handling financial transactions like deposits and withdrawals. The architecture is built on .NET 6 with a modular structure supporting user identity, game logic, and a background watchdog service for health monitoring.

Each of the startup projects (Competitions, Games, and Teams) now includes a Dockerfile that builds the application using the .NET 6.0 SDK and runtime images, enabling containerized deployment. The Dockerfiles reference the \mcr.microsoft.com/dotnet/aspnet:6.0\ and \mcr.microsoft.com/dotnet/sdk:6.0\ base images, indicating an upgrade to .NET 6. This change provides a standardized, reproducible build and run environment for each service.

src/Server/Competitions/Competitions.Startup, src/Server/Games/Games.Startup, src/Server/Teams/Teams.Startup · high confidence

Users can now create, edit, delete, and add teams to leagues, as well as retrieve lists of all leagues, available countries, and league standings. The application layer introduces commands for league creation, editing, deletion, and team assignment, alongside queries to fetch league listings, country lists, and standings data.

src/Server/Competitions/Competitions.Application/Leagues · high confidence

Users can now filter matches by their start date. This is enabled by the new \MatchByStartDateSpecification\ class, which allows querying matches based on the day, month, and year of the start date. Additionally, new specification classes for filtering by home and away teams have been introduced to support team-based match searches.

src/Server/Games/Games.Domain/Specifications · high confidence

The application now supports creating, editing, and deleting teams, as well as adding players to existing teams. These new commands allow users to manage team details including name, logo, and coach, with validation ensuring required fields are present. The implementation includes command handlers and validators for CreateTeam, EditTeam, DeleteTeam, and AddPlayer operations.

src/Server/Teams/Teams.Application/Commands · high confidence

The server now includes a \.dockerignore\ file to optimize Docker image builds by excluding unnecessary files and directories. Additionally, a new \Watchdog\ project has been added to the \BettingSystem.sln\ solution file, indicating the introduction of a background service or monitoring component. These changes facilitate containerized deployment and add a new operational component to the server architecture.

src/Server · high confidence

Introduced a new TeamRepository class that implements ITeamDomainRepository and ITeamQueryRepository. This repository provides methods to retrieve all teams, list all coaches, fetch a specific team by ID, delete a team, and retrieve players for a given team, mapping results to corresponding response models using AutoMapper.

src/Server/Teams/Teams.Infrastructure/Repositories · high confidence

Introduced a new Watchdog server component, including its entry point (Program.cs), startup configuration (Startup.cs), and Dockerfile for containerization. The server is configured to expose health check endpoints at /health using the HealthChecksUI, providing visibility into the system's operational status.

src/Server/Watchdog · high confidence

New MediatR query handlers and response models have been added to the Teams application layer, enabling retrieval of all teams, all coaches, and players for a specific team. Each query (GetAllTeamsQuery, GetCoachesQuery, GetTeamPlayersQuery) is paired with a corresponding response model (GetAllTeamsResponseModel, GetCoachesResponseModel, GetTeamPlayersResponseModel) that maps domain entities (Team, Coach, Player) to DTOs, with the player query accepting a team ID to filter results.

src/Server/Teams/Teams.Application/Queries · high confidence

Introduced a new \MatchData\ class that provides initial data for matches, including team names and base64-encoded team images. This change supports the display of team logos and winning rules within the game interface.

src/Server/Games/Games.Domain/Models/Matches · high confidence

New Entity Framework Core configuration classes have been introduced for the Country, League, and Team domain models. These configurations define primary keys, enforce required string fields with a maximum length, and establish the one-to-many relationship where a League is associated with a Country. This adds the necessary infrastructure mappings to persist these competition-related entities to the database.

src/Server/Competitions/Competitions.Infrastructure/Configurations · high confidence

The betting domain now includes core domain models for Bets, Gamblers, and Matches, along with their respective factories (BetFactory, GamblerFactory, MatchFactory) and repository interfaces. Users can now create bets with specific predictions and amounts, manage gambler profiles with deposit and withdraw capabilities, and define match details. The system also introduces winning rules (HomeWinningRule, AwayWinningRule, DrawWinningRule) that determine if a bet is profitable based on match statistics. Additionally, specifications are added to filter bets by profitability and gamblers by ID.

src/Server/Betting/Betting.Domain · high confidence

New factory implementations (LeagueFactory and TeamFactory) with corresponding interfaces (ILeagueFactory and ITeamFactory) have been added to the domain layer. These factories enforce required fields during object creation: League objects require both a name and a country, while Team objects require a name. Attempting to build these objects without the necessary data will result in an exception, ensuring data integrity at the domain level.

src/Server/Competitions/Competitions.Domain/Factories · high confidence

The identity infrastructure layer has been introduced, providing the foundation for user authentication and authorization. This includes the \IdentityDbContext\ and associated database migrations to manage user and role data in SQL Server. The system now supports user registration, login, and password changes via the \IdentityService\, which integrates with ASP.NET Core Identity. Additionally, a \JwtGeneratorService\ is implemented to issue JWT tokens for authenticated users, with support for administrator role claims. A database initializer is also included to automatically create an administrator role and a default admin user upon startup.

src/Server/Identity/Identity.Infrastructure · high confidence

The identity web layer now exposes HTTP endpoints for user registration, login, and password changes. The new IdentityController handles POST requests for Register and Login, and a PUT request for ChangePassword, delegating each to its corresponding command. WebConfiguration registers the necessary web components via AddCommonWebComponents, wiring the identity features into the application pipeline.

src/Server/Identity/Identity.Web · medium confidence

Introduced the core infrastructure setup for the Games module, including a new \InfrastructureConfiguration\ class that registers event consumers (such as \TeamLogoUpdatedEventConsumer\) and services like \ImageService\ and \GamesDbInitializer\. Additionally, added corresponding unit tests in \InfrastructureConfigurationSpecs\ to verify that repositories and event handlers are correctly registered within the dependency injection container.

src/Server/Games/Games.Infrastructure · medium confidence

The Common.Infrastructure layer now includes a new message persistence and publishing system. A MessagesDbContext tracks domain events and writes them to a Message table, which is then processed by a new MessagesHostedService that runs every 5 minutes to publish pending messages via an EventPublisher using MassTransit. The system also introduces an IDbInitializer to manage database migrations and seed initial data, along with supporting configuration extensions and repository implementations.

src/Server/Common/Common.Infrastructure · medium confidence

The application layer now includes a complete set of commands for managing the full lifecycle of a match. Users can create a new match with team and stadium details, edit match details and scores, and trigger state transitions such as starting the first or second half, pausing for halftime, finishing the match, or canceling it entirely. Each operation is backed by a dedicated command handler and validator, ensuring data integrity and proper validation of inputs like dates, team names, and scores.

src/Server/Games/Games.Application/Matches/Commands · high confidence

Users can now search for matches by start date, home team, or away team, and retrieve detailed match information including stadium names and status. The application now exposes query handlers for retrieving match listings, match details, and stadium data, enabling the frontend to fetch and display match-related information more effectively.

src/Server/Games/Games.Application/Matches/Queries · medium confidence

New repository classes (LeagueRepository and TeamRepository) have been added to the infrastructure layer, implementing the domain and query interfaces for leagues and teams. These repositories provide methods to retrieve league listings, country lists, standings, and team details, enabling the application to fetch and map competition data.

src/Server/Competitions/Competitions.Infrastructure/Repositories · high confidence

Users can now retrieve detailed information about a specific team, including its name and current points, via a new team details query. Additionally, the system now automatically updates team statistics and names in response to match results and team creation or renaming events, ensuring the stored team data remains consistent with external events.

src/Server/Competitions/Competitions.Application/Teams · high confidence

Users can now retrieve a team's original and thumbnail logo images via new query endpoints. The system also introduces event-driven updates for team names, logos, and creation, ensuring that team profile images and details are kept in sync across the application.

src/Server/Games/Games.Application/Teams · high confidence

The application now supports user registration, login, and password changes through the Identity module, introducing commands for RegisterUser, LoginUser, and ChangePassword along with their validators and request/response models. Additionally, domain and application configuration entry points have been added for the Competitions and Games modules, enabling service registration for domain factories and initial data, while also including unit tests to verify that domain services are correctly registered.

(repo-wide) · high confidence

Introduced new ASP.NET Core controllers for managing leagues and teams, exposing endpoints for retrieving all leagues, listing countries, fetching standings, and performing create, edit, add-team, and delete operations on leagues, as well as retrieving team details. The web layer is wired up via a new WebConfiguration class that registers the necessary web components.

src/Server/Competitions/Competitions.Web · high confidence

New web API endpoints have been introduced to manage matches and team logos. The MatchesController provides endpoints for searching, viewing details, and performing state transitions on matches (create, edit, start/finish halves, cancel, delete). The TeamsController exposes routes to retrieve original and thumbnail images for teams. These controllers are registered via the new WebConfiguration class.

src/Server/Games/Games.Web · medium confidence

Added new repository implementations for Match and Team entities, providing data access methods for retrieving match details, team information, and associated resources like stadium listings and team logos. This introduces the infrastructure layer for querying and managing game-related data through the specified repository interfaces.

src/Server/Games/Games.Infrastructure/Repositories · high confidence

The client application is now available for building and serving. This change introduces the foundational structure for the frontend, including a Dockerfile for containerized deployment with Nginx, an Nginx configuration for single-page application routing, and the public HTML template that loads the application's JavaScript and CSS assets. It also includes standard configuration files such as .gitignore, .prettierrc, and the public manifest for the PWA, establishing the environment for the client-side code.

src/Client · high confidence

Users can now access team-related data and perform team management operations through new API endpoints. The change introduces a TeamsController exposing read-only endpoints for listing all teams, coaches, and players, alongside administrative endpoints for creating, editing, and deleting teams. The application layer adds corresponding query repositories and configuration classes to support these operations.

src/Server/Teams/Teams.Web · medium confidence

Users can now create, close, and view bets, manage gambler profiles, and deposit or withdraw funds. The application layer adds commands for creating and closing bets, updating gambler names, and handling money deposits/withdrawals, alongside queries for listing and detailing bets and gamblers. Infrastructure changes include a new \BettingDbContext\ with EF Core configurations for Bet, Gambler, and Match entities, plus event consumers for match status and statistics updates.

src/Server/Betting/Betting.Application · high confidence

The system now includes new domain models for Leagues, Countries, and Teams, each with corresponding unit tests and fake/factory implementations. Leagues can now be associated with a Country, and Teams can be added to a League. The Team model includes logic for tracking points, with specific behaviors for recording wins (3 points) and draws (1 point). These changes provide the foundational data structures and validation logic for the competitions domain.

src/Server/Competitions/Competitions.Domain/Models · high confidence

The Betting service now includes a Dockerfile and associated configuration files (Program.cs, Startup.cs, and appsettings) to enable containerized deployment, alongside an upgrade to the .NET 6 runtime.

src/Server/Betting/Betting.Startup · medium confidence

The Common.Application layer now provides shared infrastructure: a central ApplicationConfiguration class registers MediatR, AutoMapper, and a RequestValidationBehavior that enforces FluentValidation on all requests, throwing a ModelValidationException on failure. A generic Result/Result\<T\> type is added for operation status handling, alongside contracts for current user identity, image processing, and query repositories. The Competitions.Infrastructure layer adds an InfrastructureConfiguration that registers entity framework contexts, repositories, and specific event consumers (MatchFinished, TeamCreated, TeamNameUpdated) via MassTransit. A unit test confirms that repository registration works correctly.

src/Server/Common/Common.Application, src/Server/Competitions/Competitions.Infrastructure · medium confidence

The Common.Domain layer now provides core domain primitives including an Entity base class that manages domain events, a ValueObject base class for value-based equality, and a Guard class for input validation. The update also adds a Specification pattern for query composition and interfaces for factories and initial data seeding, enabling a more structured approach to domain logic and state management.

src/Server/Common/Common.Domain · high confidence

Adds a new Common.Web module that provides core web infrastructure, including an abstract ApiController base class for handling MediatR requests, a custom ImageModelBinder for processing file uploads, and a ValidationExceptionHandlerMiddleware for consistent error handling. The module also registers current user resolution, FluentValidation, and JSON serialization, while configuring the application builder to use CORS, authentication, and health check endpoints.

src/Server/Common/Common.Web · high confidence

The Betting.Web layer now exposes RESTful controllers for managing bets and gamblers. The BetsController provides endpoints to search, view, create, mark as profitable, and close bets. The GamblersController allows creating, editing, and retrieving gambler details, and introduces new deposit and withdraw money endpoints for each gambler. These changes add the web-facing API surface for the betting domain.

src/Server/Betting/Betting.Web · medium confidence

Added new repository interfaces, IMatchDomainRepository and ITeamDomainRepository, which define the data access contracts for Match and Team entities. These interfaces specify methods for finding and deleting records, establishing the domain layer's contract for game-related data operations.

src/Server/Games/Games.Domain/Repositories · medium confidence

The system now supports a Team entity that includes a name and a logo, with strict validation on the name length. This change introduces the core domain model for teams, ensuring that team names meet minimum and maximum length requirements, and that the team has an associated image. The implementation includes a fake factory for testing and unit tests to verify that invalid names throw exceptions while valid updates are accepted.

src/Server/Games/Games.Domain/Models/Teams · high confidence

The Teams domain is initialized via a new DomainConfiguration class that registers team-related factories and initial data. The domain introduces new models for Team, Player, and Coach, each with validation logic that throws an InvalidTeamException for invalid inputs. A TeamFactory is provided to construct Team entities, and the domain configuration ensures these components are wired into the service collection.

src/Server/Teams/Teams.Domain · high confidence

The application now includes Entity Framework Core configuration classes for the new Coach, Image, Player, and Team entities. These configurations define primary keys, required fields, maximum string lengths, and relationships such as a Team having one Logo and one Coach, and a Team containing many Players. This supports the backend data layer for managing team rosters, coaching staff, and associated images.

src/Server/Teams/Teams.Infrastructure/Configurations · high confidence

The persistence layer for the Competitions module has been initialized with a new database schema. This includes the creation of a Countries table and the addition of a CountryId foreign key to the Leagues table, allowing each league to be associated with a specific country. Additionally, the relationship between Teams and Leagues has been made optional, meaning a team can exist without being assigned to a specific league.

src/Server/Competitions/Competitions.Infrastructure/Persistence · high confidence

The Identity service now includes a Dockerfile and associated configuration files (Program.cs, Startup.cs, appsettings) to enable containerized deployment, while the underlying framework has been upgraded to .NET 6. This change provides a standardized, reproducible build and run environment for the Identity startup project, allowing developers to build and run the service using Docker with the latest .NET 6 runtime and SDK images.

src/Server/Identity/Identity.Startup · medium confidence

Added InvalidMatchException and InvalidTeamException classes to the domain layer, each inheriting from BaseDomainException to handle validation errors for match and team entities.

src/Server/Games/Games.Domain/Exceptions · medium confidence

Added new repository interfaces for the domain layer: ILeagueDomainRepository and ITeamDomainRepository. The League repository now includes methods to find a league by ID, delete a league, and retrieve a country by name. The Team repository provides a method to find a team by ID. These interfaces define the contract for data access in the Competitions domain.

src/Server/Competitions/Competitions.Domain/Repositories · high confidence

The database schema for games has been restructured to improve data normalization. Image data (original and thumbnail content) is no longer stored directly in the Teams and Stadiums tables. Instead, a new 'Images' table has been introduced, and the Teams and Stadiums tables now reference images via foreign keys (LogoId, ImageId). This change also includes renaming columns to better reflect their purpose (e.g., Logo\_OriginalContent, Image\_ThumbnailContent) and adding a new 'Messages' table for event publishing. Users will see a more organized and normalized data structure, which supports better management of media assets for teams and venues.

src/Server/Games/Games.Infrastructure/Configurations, src/Server/Games/Games.Infrastructure/Persistence · high confidence

The Teams module has been updated to support richer team profiles. Teams can now store and retrieve logo images, with the database schema refactored to store image data in a separate 'Images' table linked by a foreign key, rather than storing image bytes directly in the 'Teams' table. Additionally, a 'Coaches' table has been introduced, allowing each team to be associated with a specific coach. The domain layer also introduces factory classes for constructing Match and Team objects, ensuring that required fields like start date, home/away teams, stadium, name, and logo are properly initialized.

src/Server/Games/Games.Domain/Factories, src/Server/Teams/Teams.Infrastructure/Persistence · high confidence

Added new unit tests for the BetsController, verifying controller attributes, action attributes, and the search endpoint mapping and behavior.

src/Server/Betting/Betting.Startup/Specs · high confidence

The server-side .NET projects have been upgraded to target .NET 6.0, and the client-side dependencies in src/Client/package.json have been updated to their latest stable versions, including React 17, Axios, and various testing libraries.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 29 → 27 (-2.4)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 84 → 66 (-18.6)
• Architecture 56 → 56 (+0.0)
• Maturity 31 → 31 (+0.0)
• Readiness 20 → 19 (-0.9)
• Security 27 → 27 (-0.5)
• Accessibility 44 → 38 (-6.8)

• Change coupling: Login.tsx ↔ Register.tsx (src/Client/src/pages/authentication/Login.tsx)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical vulnerability: [GHSA redacted] (src/Client/package-lock.json)
• High CVE: [GHSA redacted] (src/Client/package-lock.json)
• High CVE: [GHSA redacted] (src/Client/package-lock.json)
• …and 87 more

• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical CVE: [GHSA redacted] (src/Client/package-lock.json)
• Critical vulnerability: [GHSA redacted] (src/Client/package-lock.json)
• Documentation: no installation or build instructions (README.md)
• Documentation: no licence statement (README.md)
• End-of-life runtime: .NET net6.0
• …and 202 more

• Unchanged — 4 HTTP endpoints

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

kalintsenkov/BettingSystem was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.