yilmazmustafayilmaz/MY.OnionArchitecture

This is a .NET-based web application built on a clean, layered architecture that separates concerns across domain, application, infrastructure, and persistence layers. It provides full CRUD operations for managing articles and authors, alongside user authentication and account management. The system leverages CQRS for handling commands and queries, utilizes Entity Framework Core for data persistence, and supports real-time updates and email notifications.

The Domain layer now includes new entity classes to support content and user management. Specifically, it introduces a BaseFile class to handle file metadata (FileName, Path, Storage), which is extended by AuthorImageFile. Additionally, the system now defines Article and Author entities, establishing a one-to-many relationship where an Author can have multiple Articles and associated image files.

Domain · high confidence

The system now supports local file storage, allowing users to upload and delete files on the local filesystem. This includes a new base Storage class and a LocalStorage implementation that handles file uploads and deletions.

src/Infrastructure/Storages · high confidence

Added a new LICENSE.md file defining the MIT license for the project. Added the MY.OnionArchitecture.sln solution file, which defines the project structure for an onion architecture, including projects for Application, Persistence, Infrastructure, Domain, and Web.API. Added a comprehensive README.md file that introduces Object-Oriented Programming concepts, Clean Code principles, SOLID principles, and Design Patterns.

(repo-wide) · high confidence

The application now supports real-time updates via new SignalR hubs for articles and authors, allowing clients to receive live notifications when new content is added. Additionally, a new MailService has been introduced to handle email notifications, and token generation for authentication has been implemented to support secure access. These changes enable the system to push updates to users in real-time and send email-based alerts.

src/Infrastructure/Services · high confidence

Users can now register new accounts, log in to receive access tokens, and refresh their authentication tokens. This change introduces three new command handlers—CreateUser, LoginUser, and RefreshTokenUser—each with corresponding request and response models, along with the necessary AutoMapper mappings to convert between domain DTOs and command structures.

src/Application/Features/Users · high confidence

The application now implements a CQRS (Command Query Responsibility Segregation) architecture for articles, introducing dedicated command handlers for creating, updating, and removing articles, as well as query handlers for retrieving all articles and fetching by ID. Each operation is supported by specific request/response models, validation rules (using FluentValidation), and AutoMapper profiles to map between domain entities and API contracts. This structure enables consistent, decoupled handling of article data operations.

src/Application/Features/Articles · high confidence

Added AuthService and UserService implementations in the Persistence layer. AuthService now supports login and refresh token-based authentication, while UserService handles user creation and refresh token storage. This introduces the ability to authenticate users and manage their accounts through these new service classes.

src/Persistence/Services · high confidence

The Web.API project has been initialized with a comprehensive set of new capabilities. Authentication is supported via JWT (with Admin scheme) and refresh tokens, exposing login and token refresh endpoints in the AuthController. A global exception handler has been added to return structured JSON error responses. Logging is configured using Serilog with console, file, and PostgreSQL sinks, including a custom column writer for usernames. The API exposes controllers for managing Articles, Authors, and Users, all wired to a MediatR-based CQRS pipeline. Additionally, Swagger/OpenAPI documentation is enabled for the v1 API.

src/Web.API · medium confidence

The application now implements a CQRS (Command Query Responsibility Segregation) architecture for managing authors. This includes new command handlers for creating, updating, and removing authors, as well as query handlers for retrieving all authors and fetching a specific author by ID. The changes also introduce a mapping profile for the Author entity and validation rules for author creation and updates, enabling users to perform full lifecycle operations on author data through a structured, decoupled command and query system.

src/Application/Features/Authors · high confidence

The src/Application directory now includes a comprehensive set of new interfaces and registration logic that define the application's service contracts and infrastructure dependencies. This includes repository interfaces for Articles, Authors, and Files (split into Command and Query variants), along with base repository interfaces (IBaseRepository, ICommandRepository, IQueryRepository). The change also introduces service interfaces for authentication (IAuthService, ITokenHandlerService), user management (IUserService), mail (IMailService), storage (IStorage, IStorageService), pagination, and real-time updates via SignalR (IArticleHubService, IAuthorHubService). Additionally, it adds supporting infrastructure such as a validation filter, a file path constant, and custom exception classes, while wiring these services in ApplicationServicesRegistration and InfrastructureServiceRegistration.

src/Application · high confidence

The persistence layer now uses a generic repository pattern, introducing base classes for command (write) and query (read) operations. This provides a standardized way to add, update, and remove entities, as well as query them with optional filtering and tracking. Specific repositories for Articles, Authors, and Files now inherit from these base classes, simplifying data access for these entities.

src/Persistence/Repositories · high confidence

The application's persistence layer is now fully registered with the dependency injection container. This includes configuring the PostgreSQL database context using Entity Framework Core, setting up ASP.NET Identity with specific password policy constraints, and registering all repository interfaces (for Articles, Authors, Files, and AuthorImageFiles) along with their concrete implementations. Additionally, the UserService and AuthService are wired into the service collection, enabling the application to interact with the database and manage authentication flows.

src/Persistence · high confidence

The application's database schema is established with the initial migration (mig\_1), creating tables for AspNetUsers, AspNetRoles, Author, and Article, along with their configuration mappings. A subsequent migration (mig\_2) extends the AspNetUsers table by adding RefreshToken and RefreshTokenEndDate columns to support authentication token management.

src/Persistence/Migrations · medium confidence

A new \Context\ class has been added to the \src/Persistence/Contexts\ directory, serving as the main Entity Framework Core DbContext. It defines DbSets for \Author\, \Article\, \BaseFile\, and \AuthorImageFile\ entities, and applies specific configurations for \Author\ and \Article\. Additionally, it implements automatic timestamp management by overriding \SaveChangesAsync\ to set \CreatedDate\ on new \BaseEntity\ entries and \UpdatedDate\ on modified ones.

src/Persistence/Contexts · high confidence

The application is structured into five distinct layers—Application, Domain, Infrastructure, Persistence, and Web.API—each defined by new .csproj files that establish the project's dependency graph. These files introduce key libraries including Entity Framework Core 7.0 for data persistence, MediatR and AutoMapper for CQRS and mapping, FluentValidation, JWT authentication, Serilog for logging, and Swashbuckle for API documentation, all targeting .NET 6.0.

(dependencies) · medium confidence

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

• CAI 42 → 38 (-3.7)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 84 → 82 (-1.6)
• Architecture 84 → 84 (+0.0)
• Maturity 52 → 34 (-17.5)
• Readiness 27 → 27 (+0.0)
• Security 44 → 43 (-0.2)

• Bounded contexts not declared
• No exposed public API
• The typo 'Reqeust' is used in multiple request classes. This is a spelling inconsistency within the codebase itself (a typo), which should be corrected to 'Request'.
• The word 'Request' is consistently misspelled as 'Reqeust' in multiple command and query request classes.
• dormant codebase — no living knowledge left to concentrate
• misleading comment (src/Application/Features/Articles/Mapping/ArticleProfile.cs)

• Documentation: no installation or build instructions (README.md)
• End-of-life runtime: .NET net6.0
• Typo in class names: 'Reqeust' is used instead of the standard 'Request'. This typo is consistently applied across multiple feature modules (Users, Authors), indicating a systemic naming error rather than an isolated incident.
• WriteOnlyPrivateField (src/Application/Features/Authors/Commands/UploadAuthorImage/UploadAuthorImageCommandHandler.cs)
• WriteOnlyPrivateField (src/Web.API/Controllers/ArticlesController.cs)

• Unchanged — 15 HTTP endpoints

• Unchanged — 2 containers · 1 contexts · 0 edges

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

yilmazmustafayilmaz/MY.OnionArchitecture 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.