🛠️ HR.LeaveManagement.Clean

A clean architecture-based Human Resources Leave Management system, built with .NET 8, MediatR, and AutoMapper, demonstrating best practices in API development and domain-driven design.

📖 Overview

This project implements a comprehensive HR Leave Management system following a Clean Architecture approach. It showcases a well-structured, maintainable, and testable application built with .NET 8. The system handles various aspects of leave management, including leave types, leave requests, and leave allocations, providing a robust foundation for enterprise-level HR solutions.

---

📋 Table of Contents

1. ✨ Features
2. 🚀 Getting Started
   • Prerequisites
   • Installation
3. 📁 Project Structure
4. ⚙️ Configuration
5. 🧪 Testing
6. 📖 API Documentation
7. 📊 Performance Optimization
8. 🔍 Observability
9. 📦 Design Patterns
10. 🛠️ Contributing
11. 📜 License
12. 🔗 Additional Resources

---

✨ Features

• Clean Architecture — Organized into Domain, Application, Infrastructure, and API layers for clear separation of concerns.
• MediatR Implementation — Utilizes MediatR for handling commands, queries, and events, promoting a decoupled and testable codebase.
• AutoMapper Integration — Seamless object-to-object mapping to reduce boilerplate code and improve maintainability.
• Centralized Exception Handling — Robust error management through custom middleware for consistent API responses.
• CRUD Operations for Leave Management — Comprehensive functionalities for managing Leave Types, Leave Requests, and Leave Allocations.
• API Development with .NET 8 — Modern RESTful API built on .NET 6, leveraging its latest features and performance improvements.
• Unit and Integration Testing — Dedicated test projects ensuring code quality and reliability.
• Swagger/OpenAPI Documentation — Automatically generated API documentation for easy consumption and testing.

🔝 Back to Top

---

🚀 Getting Started

Prerequisites

Ensure you have the following installed:

• .NET 8 SDK
• SQL Server (or any compatible database) — For persistence layer.
• Visual Studio 2022 (or VS Code with C# extensions) — Recommended IDE.

Installation

1. Clone the repository:

   git clone https://github.com/ahmadabdelbary2001/HR.LeaveManagement.Clean.git
   cd HR.LeaveManagement.Clean

2. Restore dependencies:

   dotnet restore

3. Configure Database: Update the connection string in HR.LeaveManagement.Api/appsettings.json and HR.LeaveManagement.Api/appsettings.Development.json to point to your SQL Server instance.

4. Apply Migrations: Navigate to the HR.LeaveManagement.Persistence project and apply database migrations:

   dotnet ef database update --project HR.LeaveManagement.Persistence

5. Build and run the API project:

   dotnet run --project HR.LeaveManagement.Api

   The API will typically run on https://localhost:5296 (or a similar port).

🔝 Back to Top

📁 Project Structure

HR.LeaveManagement.Clean/
├── HR.LeaveManagement.Api/               # ASP.NET Core Web API project
│   ├── Controllers/                      # API Endpoints
│   ├── Middleware/                       # Custom Middleware (e.g., Exception Handling)
│   ├── Models/                           # API-specific models (e.g., Email settings)
│   ├── Program.cs                        # Application startup and service registration
│   └── appsettings.json                  # Configuration files
├── HR.LeaveManagement.Application/       # Application layer (Core business logic)
│   ├── Contracts/                        # Interfaces for services and repositories
│   ├── Exceptions/                       # Custom exceptions
│   ├── Features/                         # MediatR handlers (Commands, Queries, Events)
│   ├── MappingProfiles/                  # AutoMapper profiles
│   ├── Models/                           # Application-specific models
│   └── ApplicationServiceRegistration.cs # Dependency Injection for Application services
├── HR.LeaveManagement.Domain/            # Domain layer (Enterprise business rules and entities)
│   ├── Common/                           # Base entities and common domain logic
│   ├── Entities/                         # Core domain entities (LeaveType, LeaveRequest, LeaveAllocation)
│   └── HR.LeaveManagement.Domain.csproj  # Project file
├── HR.LeaveManagement.Infrastructure/    # Infrastructure layer (External services, e.g., Email, Logging)
│   └── EmailService/                     # Email sending implementation
├── HR.LeaveManagement.Persistence/       # Persistence layer (Data access, e.g., Entity Framework Core)
│   ├── Configurations/                   # Entity Framework Core configurations
│   ├── Repositories/                     # Concrete implementations of domain repositories
│   ├── DatabaseContext/                  # DbContext for Entity Framework Core
│   └── PersistenceServiceRegistration.cs # Dependency Injection for Persistence services
├── HR.LeaveManagement.Application.UnitTests/ # Unit tests for the Application layer
├── HR.LeaveManagement.Persistence.IntegrationTests/ # Integration tests for the Persistence layer
└── HR.LeaveManagement.Clean.sln          # Solution file

🔝 Back to Top

⚙️ Configuration

Environment Variables

Connection strings and other sensitive configurations should be managed securely. For local development, you can use appsettings.Development.json or user secrets.

Settings

• Connection Strings — Located in appsettings.json and appsettings.Development.json for database connectivity.
• CORS Policy — Configured in Program.cs to allow all origins, headers, and methods for development purposes. Adjust as needed for production environments.
• Swagger/OpenAPI — Enabled in Program.cs for API documentation and testing, typically only in development environments.

🔝 Back to Top

🧪 Testing

Run test suite with:

dotnet test

Test Coverage:

• Unit Tests: HR.LeaveManagement.Application.UnitTests/ ✅
• Integration Tests: HR.LeaveManagement.Persistence.IntegrationTests/ 🔗

🔝 Back to Top

📖 API Documentation

The API documentation is generated using Swagger/OpenAPI and can be accessed when the application is running (typically at https://localhost:5296/swagger).

Authentication

This project currently does not implement explicit authentication/authorization mechanisms. All API endpoints are publicly accessible. For production use, consider integrating IdentityServer4 or ASP.NET Core Identity.

Example API Endpoint (Conceptual - based on project structure)

• Endpoint: GET /api/LeaveType
• Description: Retrieves a list of all leave types.
• Response Codes:
  • 200 OK — Success ✅
  • 500 Internal Server Error — Server error 🔥

🔝 Back to Top

📊 Performance Optimization

• Asynchronous Processing — Utilizes async/await for non-blocking I/O operations, improving responsiveness.
• Caching — While not explicitly implemented in the provided code, a caching mechanism (e.g., Redis, in-memory cache) can be integrated into the Infrastructure layer to reduce database load.
• Connection Pooling — Managed by Entity Framework Core for efficient database connection reuse.
• Minimal API Surface — The API is designed to expose only necessary endpoints, reducing overhead.

🔝 Back to Top

🔍 Observability

• Centralized Exception Handling — Custom middleware (ExceptionMiddleware) in the API layer captures and handles exceptions consistently.
• Logging — Can be integrated using popular logging frameworks like Serilog or NLog for structured logging across different environments.
• Health Checks — ASP.NET Core Health Checks can be added to monitor the health of various components (database, external services).

🔝 Back to Top

📦 Design Patterns

List of implemented patterns with brief descriptions:

• Clean Architecture — Separates concerns into distinct layers (Domain, Application, Infrastructure, Presentation) to improve maintainability, testability, and scalability.
• Mediator Pattern (MediatR) — Decouples senders from receivers, allowing for a more flexible and testable command/query/event handling system.
• Repository Pattern — Abstracts the data access layer, providing a clean API for interacting with data sources.
• Unit of Work Pattern — Ensures atomicity of transactions by coordinating multiple repository operations within a single transaction.
• Dependency Injection — Manages dependencies between components, promoting loose coupling and testability.
• AutoMapper — Simplifies object-to-object mapping, reducing manual mapping code.

🔝 Back to Top

🛠️ Contributing

1. Fork the repository 🍴
2. Create your feature branch: git checkout -b feature/my-feature
3. Commit changes: git commit -m 'Add my feature'
4. Push to branch: git push origin feature/my-feature
5. Open a Pull Request

Please adhere to the existing coding style and run tests before submitting.

🔝 Back to Top

📜 License

This project is licensed under the MIT License. See the LICENSE file for details.

🔗 Additional Resources

• Project Wiki 📚
• Microsoft .NET Microservices Architecture Guide 🗺️
• MediatR GitHub Repository 💬
• AutoMapper Documentation

🔝 Back to Top

Made with ❤️ by @Ahmad Abdelbary