buraksenyurt/project-lighthouse-social

Lighthouse Social is a .NET 9 application that manages lighthouse records, user accounts, and photo uploads with associated comments. It provides a Web API and an OData endpoint for data access, supported by a backoffice interface for administrative management. The system employs an event-driven architecture using RabbitMQ for asynchronous processing and implements saga patterns to ensure data consistency during complex operations like photo uploads.

The application now supports retrieving secrets from HashiCorp Vault via a new \VaultSecretManager\ implementation. This component reads configuration (address, token, mount point) from \VaultSettings\, connects to the Vault service using the \VaultSharp\ client, and exposes methods to fetch individual secrets or entire secret dictionaries from a specified path, returning results via the application's standard Result pattern.

src/LighthouseSocial.Infrastructure/SecretManager · high confidence

The application now supports storing and retrieving photos using a MinIO-compatible object storage backend. This change introduces a new \PhotoStorageService\ that implements the \IPhotoStorageService\ contract, enabling users to upload, download, and delete photo files. Configuration for the storage connection (endpoint, credentials, bucket name, and SSL settings) is handled via a new \MinioSettings\ class, allowing the system to integrate with external MinIO instances for persistent photo storage.

src/LighthouseSocial.Infrastructure/Storage · high confidence

Introduced the ISaga and ISagaStep interfaces within the distributed transaction common module. These interfaces define the contract for executing saga workflows and individual steps, including compensation logic, enabling the implementation of distributed transaction patterns in the application.

src/LighthouseSocial.Application/Common/DistribtedTransaction · high confidence

A new sample client application (TerminalApp) has been added, providing an interactive command-line interface for testing core platform capabilities. Users can now run a local CLI to perform Lighthouse CRUD operations, upload photos to Minio storage, execute full composition workflows, and test country data caching via Redis. The app is configured via appsettings.json to connect to local instances of Vault, Minio, and Redis.

src/Clients/TerminalApp · high confidence

The application layer now supports a pipeline architecture for handling requests, introducing four new behaviors: CancellationBehavior (handles cancellation tokens and returns a 'Operation was cancelled' result), ExceptionHandlingBehavior (catches exceptions and returns a 'Unexpected error occured' result), LoggingBehavior (logs request start and completion), and PerformanceBehavior (logs warnings for requests taking longer than 1000ms). These behaviors are wired through a new PipelineDispatcher that resolves handlers and applies behaviors in reverse order, allowing for cross-cutting concerns to be applied uniformly to all requests processed via this dispatcher.

src/LighthouseSocial.Application/Common/Pipeline · high confidence

The application now includes an auditing system for user comments, implemented via the \ICommentAuditor\ interface in the infrastructure layer. Two providers are introduced: \DefaultCommentAuditor\, which performs local keyword filtering against a hardcoded list of banned words, and \ExternalCommentAuditor\, which sends comment text to an external moderation service endpoint. Both implementations return a standardized \Result\<bool\>\ indicating whether the text is clean, ensuring consistent error handling and logging for comment moderation operations.

src/LighthouseSocial.Infrastructure/Auditors · high confidence

This change introduces foundational domain classes in the Common layer, including abstract base classes for entities (EntityBase) and enumerations (EnumerationBase), as well as a complete event-driven messaging contract. Specifically, it defines the IEvent interface and EventBase abstract class to standardize event structure (ID, timestamp, type, aggregate ID), and introduces the IEventPublisher interface to define the contract for publishing single or batches of events asynchronously. These components provide the structural basis for implementing domain events and their subsequent publishing mechanisms within the application.

src/LighthouseSocial.Domain/Common · high confidence

Introduced new domain value objects to support the 'Top Lighthouses' feature: Coordinates for geographic location, PhotoMetadata for image details, Rating with validation for scores between 1 and 10, and LighthouseWithStats to aggregate lighthouse information including average score and photo count.

src/LighthouseSocial.Domain/ValueObjects · high confidence

A new standalone .NET application has been introduced to consume messages from a RabbitMQ broker. This consumer connects to localhost on port 5672, declares a topic exchange named 'lighthouse-project-events', and binds to a queue named 'lighthouse-project-queue' using the routing key pattern 'lighthouse.\*'. It processes incoming messages by logging the routing key and body content to the console, operating with automatic acknowledgment enabled.

src/RabbitMqConsumer · high confidence

New use-case classes have been introduced in the TerminalApp client to orchestrate specific business workflows via the console. LighthouseManagement enables creating, retrieving, and listing lighthouse records; PhotoManagement handles uploading photos and downloading associated image files; ViewManagement loads and displays country data; and Composition ties these services together into a full end-to-end test workflow. These components serve as the integration layer for testing the application's core features.

src/Clients/TerminalApp/UseCases · high confidence

The application layer now registers its service dependencies, including handlers for lighthouse, photo, comment, and user operations, along with pipeline behaviors for cancellation, logging, performance, and exception handling. A new feature allows retrieving a list of all countries via the GetAllCountriesHandler, which fetches country data and returns it as a list of country DTOs.

src/LighthouseSocial.Application · high confidence

The infrastructure layer now introduces a \CachedConfigurationService\ that securely retrieves and caches sensitive settings—such as database connection strings, MinIO credentials, RabbitMQ connection details, and Keycloak authentication parameters—from a secret vault. This service supports both in-memory and distributed (Redis) caching strategies to reduce vault latency. Additionally, new configuration classes have been added to define settings for Elasticsearch and Graylog logging integrations, as well as specific records for MinIO and RabbitMQ, enabling the application to connect to these external services using centralized, cached configuration data.

src/LighthouseSocial.Infrastructure/Configuration · high confidence

The application now includes handlers for adding, deleting, and retrieving comments on photos. The add operation enforces business rules by validating input, checking for duplicate comments, verifying user and photo existence, and auditing comment text for appropriateness before persistence. All comment operations publish domain events to track creation, failure, and success states, providing a consistent result pattern for error handling.

src/LighthouseSocial.Application/Features/Comment · high confidence

The application layer now exposes a set of new interfaces in the ExternalServices contracts directory to define how the system interacts with external data sources. These include ICountryService for retrieving country lists, ILighthouseService for managing lighthouse entities (including top lists, details, CRUD operations, and paging), IPhotoService for retrieving photos by user or lighthouse ID and deleting them, IPhotoUploadService for uploading new photos, and IUserService for creating and retrieving user accounts. These interfaces establish the boundaries for external service integrations within the application.

src/LighthouseSocial.Application/Contracts/ExternalServices · high confidence

The domain layer now exposes a comprehensive set of events to track the lifecycle of key entities. For user creation, events cover the requested, created, and failed stages. Photo uploads are tracked through a saga pattern, emitting events for the start, completion, failure, and compensation phases, alongside standard upload and save events. Comment creation is similarly modeled with requested, created, and failed events. Finally, lighthouse creation is supported by events for the requested, created, and failed states, enabling downstream services to react to these domain changes.

src/LighthouseSocial.Domain/Events · high confidence

The LighthouseSocial.WebApi project has been introduced, providing the HTTP entry point for the application. It includes HTTP test files for lighthouse and photo endpoints, and the Program.cs file configures the ASP.NET Core pipeline with Keycloak authentication, Serilog logging, and integration with external services including MinIO storage, Redis caching, RabbitMQ messaging, and Graylog/Elasticsearch logging.

src/LighthouseSocial.WebApi · high confidence

This change introduces the foundational structure for the Project Lighthouse Social application. It adds a comprehensive docker-compose.yml file to orchestrate local infrastructure, including PostgreSQL, Keycloak, Vault, Redis, MinIO, RabbitMQ, SonarQube, and Graylog. A SQL script (scripts.sql) is provided to initialize the database with tables for users, lighthouses, photos, and comments, along with sample data and an outbox pattern table for event sourcing. Additionally, a Postman collection is added to facilitate API testing for moderation and authentication endpoints, and a .dockerignore file is configured to optimize the build context.

(repo-wide) · high confidence

This change introduces the Lighthouse Social Backoffice, a new Razor Pages-based administrative interface for managing lighthouse data. The application provides a dashboard for creating new lighthouses (including name, country, coordinates, and photo uploads with validation), viewing paginated lists of existing lighthouses, and deleting entries. It features a Bootstrap-styled layout with a sidebar navigation, an error handling page, and a privacy policy page. The backend integrates with external services via HTTP clients for lighthouse, country, and photo operations, utilizing in-memory caching for country data.

src/LighthouseSocial.Backoffice · high confidence

The LighthouseSocial.sln file has been created, defining the initial project structure for the application. This includes core domain, application, infrastructure, and data projects, alongside Web API, OData API, and Backoffice services. The solution also incorporates a RabbitMQ-based event worker for message processing, a terminal client application, and a comprehensive set of unit and integration test projects.

src · high confidence

A new JudgeDredd microservice has been added to provide content moderation capabilities. It exposes a POST /moderate endpoint that accepts a comment and returns whether it is flagged, utilizing the OpenAI Moderation API (omni-moderation-latest) via the OpenApiCommentAuditService. The service is configured as a .NET 9.0 ASP.NET Core application, includes Docker support (Dockerfile, .dockerignore), and requires an API key configured in appsettings.json.

src/JudgeDredd · high confidence

A new background worker service has been added to consume RabbitMQ messages and process domain events using a strategy pattern. The service registers a hosted consumer that listens to the 'lighthouse-project-queue' on the 'lighthouse-project-events' exchange, deserializes incoming payloads, and dispatches them to specific handlers (currently supporting the 'PhotoUploaded' event). This architecture allows for modular handling of different event types via the IEventStrategy interface, with dependency injection configured in Program.cs to wire the consumer, dispatcher, and strategy implementations.

src/LighthouseSocial.EventWorker · high confidence

The caching infrastructure now supports Redis in addition to the existing in-memory cache. A new \ICacheService\ interface defines the contract, implemented by \MemoryCacheService\ (wrapping \IMemoryCache\) and \RedisCacheService\ (using \StackExchange.Redis\ and \IConnectionMultiplexer\). Both implementations serialize/deserialize values via \System.Text.Json\ and return a \Result\ type to handle success or failure states, allowing the application to switch between or combine caching strategies.

src/LighthouseSocial.Infrastructure/Caching · high confidence

Added a new set of Data Transfer Objects (DTOs) to the application layer to define the shape of data exchanged for core entities. This includes \UserDto\, \LighthouseDto\, \PhotoDto\ (with an optional \IsPrimary\ flag), \CommentDto\, and \CountryDto\. It also introduces specialized DTOs for specific features: \LighthouseTopDto\ and \TopDto\ (with validation for count limits) to support a new 'Top Lighthouses' capability, \QueryableLighthouseDto\ for enriched listing views, \LighthouseUpsertDto\ for creation and updates, and \PagingDto\ to enable pagination for list operations.

src/LighthouseSocial.Application/Dtos · high confidence

New service classes (CountryService, LighthouseService, PhotoService, PhotoUploadService, UserService) have been added to the application layer. These services act as the primary interface for business logic, delegating operations to internal request handlers via a pipeline dispatcher. This introduces capabilities such as paginated lighthouse retrieval, top lighthouse ranking, photo uploads via a saga pattern, and user management by ID, email, or subscription ID.

src/LighthouseSocial.Application/Services · high confidence

The domain layer now includes foundational entity classes for the application's core concepts: User, Lighthouse, Photo, Comment, and Country. The Photo entity supports an IsPrimary flag to designate a main image and maintains a collection of associated Comments. Additionally, enumeration types for CameraType (SLR, DSLR, Mirrorless, Phone) and PhotoCategory (Sunset, Historical, Storm, Sundown) have been added to standardize photo metadata classification.

src/LighthouseSocial.Domain/Entities · high confidence

The Lighthouse application layer now supports full CRUD operations (Create, Read, Update, Delete) and specialized queries (Get Top, Get Paged) via dedicated handlers. These handlers enforce a consistent 'Result' pattern for success/failure handling and integrate with an event publisher to emit domain events (e.g., LighthouseCreationRequested, LighthouseCreated) upon state changes. The implementation includes validation via FluentValidation, country data verification, and pagination support for listing lighthouses.

src/LighthouseSocial.Application/Features/Lighthouse · high confidence

The Web API now exposes dedicated controllers for managing lighthouses, countries, and photos. Users can create, update, delete, and retrieve lighthouses (including paged and top-list views) via the LighthouseController, fetch available countries via the CountryController, and manage photos through the PhotoController (retrieving by user, lighthouse, or ID, and deleting) and the PhotoUploadController (uploading images with metadata and an optional primary flag, enforcing a 5 MB limit and JPG/PNG formats).

src/LighthouseSocial.WebApi/Controllers · high confidence

A new OData-based API service has been added to the LighthouseSocial platform, exposing a \Lighthouses\ entity set at the \/odata\ route. This allows clients to retrieve lighthouse data with advanced filtering, sorting, and projection capabilities (e.g., filtering by name, location, or rating metrics) using standard OData query parameters. The service is configured to support select, filter, orderby, expand, and count operations, with a maximum top result limit of 100 items.

src/LighthouseSocial.ODataApi · high confidence

The application now includes a dedicated data access layer in the LighthouseSocial.Data project, introducing a new dependency injection setup that registers repository services (Lighthouse, Photo, Comment, User, OData, and Country) and a database connection factory. The connection factory supports multiple initialization strategies: direct connection strings, factory functions, and automatic retrieval from a cached Vault configuration service, with logging for successful or failed Vault lookups. This change establishes the foundational infrastructure for database interactions, replacing previous ad-hoc connection handling with a structured, injectable approach.

src/LighthouseSocial.Data · high confidence

Added application-layer handlers for creating users and retrieving them by email, ID, or sub-ID. The creation handler validates input, checks for duplicates, persists the user, and publishes domain events (UserCreationRequested, UserCreated, UserCreationFailed) via an event publisher. The retrieval handlers fetch user data from the repository and return it as a DTO, handling validation and error cases appropriately.

src/LighthouseSocial.Application/Features/User · high confidence

The system now uses RabbitMQ as the underlying transport for publishing domain events. The new \RabbitMqEventPublisher\ handles connection management, declares a topic exchange, and serializes events to JSON with camel-case property naming. Events are published with persistent delivery and routed using a key pattern of \lighthouse.\<eventtype\>\, ensuring reliable asynchronous communication for event-driven workflows.

src/LighthouseSocial.Infrastructure/Messaging · high confidence

New FluentValidation validators have been introduced for Comment, Lighthouse, Photo, and User DTOs to enforce data integrity at the application layer. Comment submissions now require non-empty text (max 250 chars), a valid rating (1-10), and valid Photo and User IDs. Lighthouse upserts validate the name length, country ID range, and geographic coordinates. Photo uploads are restricted to specific image formats (.jpg, .jpeg, .png, .gif), require a valid upload date, and enforce recognized camera types. User creation validates that the ID, SubId, Fullname, and Email are present, with Email format and length constraints applied.

src/LighthouseSocial.Application/Validators · high confidence

The application contract interfaces for comment auditing, photo storage, and secret management have been updated to return a generic Result type instead of raw values or exceptions. This change standardizes error handling across these services, allowing callers to explicitly handle success or failure states for operations such as checking text cleanliness, saving or retrieving photos, and fetching secrets.

src/LighthouseSocial.Application/Contracts · high confidence

The application now uses a new \InfrastructureBuilder\ in the \DependencyInjection\ module to configure core services, replacing previous registration methods. This change introduces a fluent API for setting up Keycloak authentication (with settings sourced from a vault), Redis or memory caching, MinIO storage, Serilog sinks for Elasticsearch and Graylog, and RabbitMQ messaging. Additionally, a \HostedConfigurationService\ now runs at startup to pre-warm the cached configuration service, ensuring secrets and settings are available before the application fully initializes.

src/LighthouseSocial.Infrastructure · high confidence

The repository implementations in src/LighthouseSocial.Data/Repositories have been rewritten to use Dapper for database interactions and the Result pattern for return types, replacing previous data access mechanisms. This change standardizes error handling across all entities (Lighthouse, User, Photo, Comment, Country) by wrapping operations in Result objects, and introduces new capabilities such as paginated lighthouse retrieval, a 'Top Lighthouses' query, and an OData-compatible repository for lighthouse statistics. Additionally, a cached country data reader was added to improve performance for country lookups.

src/LighthouseSocial.Data/Repositories · high confidence

The application layer now includes shared infrastructure types to standardize how operations report outcomes and handle data retrieval. A generic \Result\<T\>\ class provides a consistent way to represent success or failure with associated data or error messages, while a non-generic \Result\ variant handles void operations. Additionally, a \PagedResult\<T\>\ model supports paginated data responses, and a \ServiceResponse\<T\>\ class with a \ServiceResponseStatus\ enum offers an alternative response structure. These changes establish a unified pattern for service responses across the application.

src/LighthouseSocial.Application/Common · high confidence

The photo feature handlers (upload, delete, get by ID, get by lighthouse, get by user, and get raw photo) have been refactored to implement the IHandler contract and return a Result type instead of void or raw exceptions. This change standardizes error handling across all photo operations, ensuring that failures in validation, storage, or repository access are explicitly captured and returned. Additionally, the upload process now publishes specific domain events (PhotoUploadRequested, PhotoUploadFailed, PhotoSavedToRepository, PhotoUploaded) to support asynchronous workflows and external integrations, while other handlers remain synchronous but consistent in their return structure.

src/LighthouseSocial.Application/Features/Photo · high confidence

The application's repository interfaces (ICommentRepository, ICountryDataReader, ILighthouseODataRepository, ILighthouseRepository, IPhotoRepository, and IUserRepository) have been updated to return a Result wrapper type instead of raw entities or void. This change standardizes error handling across data access operations, ensuring that callers explicitly handle success or failure states for methods such as AddAsync, GetByIdAsync, and GetByPhotoIdAsync.

src/LighthouseSocial.Application/Contracts/Repositories · high confidence

Photo uploads now use a saga pattern that coordinates file storage and metadata persistence as distinct steps. If the file upload succeeds but metadata saving fails (or an unexpected error occurs), the saga compensates by deleting the uploaded file and removing the partial metadata record, ensuring data consistency. This change is implemented in the \PhotoUploadSaga\ orchestration and its \FileUploadStep\ and \MetadataSaveStep\ components within the application's photo feature.

src/LighthouseSocial.Application/Features/Photo/Saga · high confidence

Added integration tests for the AddComment handler; Added unit tests for Lighthouse application handlers; Added unit tests for infrastructure components; Added unit tests for photo management handlers.

The solution is initialized with multiple projects targeting .NET 9.0, establishing the foundational architecture. Key dependencies include Dapper and Npgsql for data access, FluentValidation for input validation, RabbitMQ.Client for messaging, and Serilog with Graylog and Elasticsearch sinks for logging. Infrastructure services are introduced via Keycloak for authentication, StackExchangeRedis and Memory for caching, and Minio and VaultSharp for storage and secrets management. The API layer utilizes Microsoft.AspNetCore.OpenApi and OData, while the client and worker components rely on standard .NET hosting and configuration packages.

(dependencies) · high confidence

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

• CAI 51 → 48 (-3.0)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 84 → 79 (-4.5)
• Architecture 78 → 87 (+9.3)
• Maturity 59 → 61 (+2.2)
• Readiness 35 → 34 (-1.3)
• Security 64 → 64 (-0.2)
• Domain Modelling 53 (new)
• Event-Driven 73 → 73 (+0.0)
• Accessibility 71 → 68 (-2.3)

• Bounded contexts not declared
• Change coupling: CommentRepository.cs ↔ PhotoRepository.cs (src/LighthouseSocial.Data/Repositories/CommentRepository.cs)
• Change coupling: LighthouseService.cs ↔ PhotoService.cs (src/LighthouseSocial.Application/Services/LighthouseService.cs)
• Coverage not measured — analyzer environment
• Duplicated block (11 lines × 2) (src/LighthouseSocial.Application/Features/Photo/Saga/PhotoUploadSaga.cs)
• Duplicated block (12 lines × 2) (src/LighthouseSocial.Data/Repositories/UserRepository.cs)
• Duplicated block (14 lines × 2) (src/LighthouseSocial.Data/Repositories/LighthouseRepository.cs)
• High: security finding (details withheld)
• High: security finding (details withheld)
• LLM evaluation failed
• Monorepo: only 1 of 3 solutions was scored
• No exposed public API
• Secret: jwt (Project Lighthouse Social.postman_collection.json)
• Secret: jwt (Project Lighthouse Social.postman_collection.json)
• Secret: jwt (Project Lighthouse Social.postman_collection.json)
• Secret: jwt (Project Lighthouse Social.postman_collection.json)
• Secret: jwt (Project Lighthouse Social.postman_collection.json)
• Small-team knowledge concentration
• Typo in namespace/assembly path: 'Distribted' instead of 'Distributed'. This typo is present in the namespace path, which is inconsistent with the correct spelling 'Distributed' used in standard .NET libraries and likely intended here.
• Typo in service client name: 'Ligthouse' instead of 'Lighthouse'. This typo is present in the interface, implementation, and usage, but the misspelling itself is an inconsistency with the correct domain term 'Lighthouse' used elsewhere in the codebase (e.g., LighthouseRepository, LighthouseController).

• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (10 lines × 2) (src/Clients/TerminalApp/UseCases/Composition.cs)
• Duplicated block (11 lines × 2) (src/LighthouseSocial.Application/Features/Photo/Saga/PhotoUploadSaga.cs)
• Duplicated block (12 lines × 3) (src/LighthouseSocial.Data/Repositories/UserRepository.cs)
• Duplicated block (14 lines × 2) (src/LighthouseSocial.Data/Repositories/LighthouseRepository.cs)
• Duplicated block (15 lines × 2) (src/LighthouseSocial.Application/Features/Photo/GetPhotosByLighthouseHandler.cs)
• Duplicated block (15–16 lines × 3) (src/LighthouseSocial.Application/Features/User/GetUserByEmailHandler.cs)
• Duplicated block (25 lines × 2) (src/LighthouseSocial.Backoffice/Services/LigthouseServiceClient.cs)
• Duplicated block (3–13 lines × 3) (src/LighthouseSocial.Data/Repositories/LighthouseRepository.cs)
• Duplicated block (6 lines × 7) (src/LighthouseSocial.Domain/Events/Photo/PhotoSavedToRepository.cs)
• Duplicated block (7 lines × 2) (src/LighthouseSocial.Domain/Events/User/UserCreationFailed.cs)
• Duplicated block (7 lines × 4) (src/LighthouseSocial.Domain/Events/Photo/PhotoSavedToRepository.cs)
• Duplicated block (8 lines × 2) (src/LighthouseSocial.Domain/Events/Lighthouse/LighthouseCreationFailed.cs)
• Duplicated block (8 lines × 3) (src/LighthouseSocial.Domain/Events/Photo/PhotoUploadSagaCompleted.cs)
• End-of-life runtime: .NET net9.0
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• …and 30 more

• Unchanged — 15 HTTP endpoints

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

buraksenyurt/project-lighthouse-social 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.