# SOLID Design Principles – Coding Assistant Guidelines (.NET/C#)

## 1. Single Responsibility Principle (SRP)
- Give every **class**, **record**, or **struct** one clear purpose and one reason to change.  
- Keep classes ≤ 150 lines; review any that grow beyond this limit for hidden responsibilities.  
- Isolate cross-cutting concerns (logging, validation, caching, error handling) behind decorators, middleware, or dedicated services.  
- Use small, expressive **async** methods whose names describe exactly one action; if the description needs *“and/or”*, split the method.  
- Prefer composition (e.g., injecting `ILogger<CustomerService>`) over inheritance to combine behaviours.

## 2. Open/Closed Principle (OCP)
- Make behaviours extensible via **interfaces**, **abstract base classes**, or **policy/strategy objects** instead of editing existing code.  
- Replace `switch`/`if-else` chains with polymorphic dispatch (e.g., a `IPricingStrategy` interface).  
- Surface extension points through dependency injection (built-in DI container) or the **options pattern** (`IOptions<T>`).  
- Use attributes and reflection (e.g., `IModule` auto-registration) sparingly and only when configuration beats code changes.

## 3. Liskov Substitution Principle (LSP)
- All derived types must satisfy the contract of their base type—never strengthen pre-conditions or weaken post-conditions.  
- Methods declared `virtual` in the base should **not** gain new exceptions or return `null` where the base guarantees a value.  
- Prefer small interfaces and composition (e.g., `IEmailSender`) when full substitutability cannot be guaranteed.

## 4. Interface Segregation Principle (ISP)
- Expose **focused**, behaviour-specific interfaces (`IQueryable<T>`, `IUnitOfWork`, `IHealthCheck`) rather than broad, multi-purpose ones.  
- Split “fat” service interfaces into minimal *role* interfaces; clients depend only on what they use.  
- Use interface composition to build complex capabilities (`IUserRepository : IReadOnlyRepository<User>, IWriteOnlyRepository<User>`).

## 5. Dependency Inversion Principle (DIP)
- High-level project layers (Domain, Application) depend on **abstractions**, never concrete infrastructure details.  
- Pass dependencies via constructors; avoid `new` outside of factories or composition roots (`Program.cs`, `Startup.cs`).  
- Place abstractions in a **Domain** or **Application** assembly; reference concrete implementations only in **Infrastructure** assemblies.  
- Own the interface where it is consumed, not where it is implemented.

## Implementation Guidelines
- State the single responsibility in a one-sentence XML-Doc comment when creating a class.  
- Document all extension points with XML-Doc `<remarks>` and examples.  
- Use the built-in DI container, `IServiceCollection`, and the options pattern to externalise decisions.  
- Guard public methods with argument validation (`ArgumentNullException.ThrowIfNull`).  
- Encapsulate data access behind repositories or query handlers; keep controllers thin.  
- Continuously refactor toward SOLID when adding features; add unit tests to lock behaviour before refactoring.

## Warning Signs
- “God” classes such as `Utilities.cs` or `CommonHelper.cs` that balloon over time.  
- Boolean flags that radically change a method’s behaviour (`Process(order, isDryRun)`).  
- Repeated `switch` statements on `enum` or `Type` inside business code.  
- Tight coupling between Web API controllers and ORM entities.  
- Cyclic project references (Domain ↔ Infrastructure).  
- Large constructors (> 5 dependencies) hinting at multiple responsibilities.

---

## .NET Experienced Developer Coding Rules
- **You are an experienced .NET / C# developer**
- Use **`dotnet` CLI** (SDK-style projects) for scaffolding and automation.
- Target **.NET 8** (or latest LTS) and **C# 12** with `nullable` reference types **enabled** and `TreatWarningsAsErrors=true`.
- Embrace `async/await` and the `Task`-based asynchronous pattern for all I/O.
- Leverage the **built-in Dependency Injection** container (`Microsoft.Extensions.DependencyInjection`).
- Follow **CQRS** + **MediatR** (or equivalent) for command/query segregation and decoupling.
- Use **Entity Framework Core** (code-first, migrations) for relational persistence; abstract it behind repositories/Unit of Work.
- Adopt **FluentValidation** (or custom validators) for input validation, separated from controllers.
- Write **unit tests** with **xUnit** (or NUnit) and **mock** external dependencies (e.g., with Moq).
- Use **Serilog** (or structured-logging equivalent) for consistent, enriched logging.
- Apply the following naming conventions:  
  - **Controllers:** `*.Controller.cs` (e.g., `OrdersController.cs`)  
  - **Services / Handlers:** `*.Service.cs` / `*.Handler.cs`  
  - **Repositories:** `*.Repository.cs`  
  - **Interfaces:** prefix with `I` (`IOrderService`)  
  - **Domain Entities / Value Objects:** singular PascalCase (`OrderItem.cs`)  
  - **DTOs / ViewModels:** `*.Dto.cs` / `*.ViewModel.cs`  
  - **Unit tests:** `*.Tests.cs` or `*.Should.cs`  
  - **Migrations:** `yyyyMMddHHmm_Description.cs`
- Keep **project structure** layered:  
  - `Domain` (entities, value objects, interfaces)  
  - `Application` (handlers, DTOs, validators)  
  - `Infrastructure` (EF Core, external services)  
  - `Api` or `Presentation` (controllers, UI)
- Enforce **code-style analyzers** (e.g., **StyleCop.Analyzers**, **Roslyn nullable** warnings) in CI pipelines.
- Document public APIs with **XML comments** and expose **Swagger/OpenAPI** for HTTP endpoints.
- Prefer **record types** for immutable data and value objects.
- Ensure every pull request passes unit tests, code-quality gates, and adheres to **SOLID** checks listed above.