> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/technical-guidelines-code-standards-and-tech-stack/solid-clean-code-and-design-patterns/solid-in-aic-projects.md).

# SOLID in AIC Projects

## Purpose

SOLID principles help AIC teams create maintainable, testable and extensible software.

SOLID is not a slogan. It is a practical design discipline used to reduce change risk.

## Single Responsibility Principle

A class should have one reason to change.

Good:

```csharp
public sealed class CaseNumberGenerator
{
    public string Generate(DateOnly date, int sequence) => $"CASE-{date:yyyyMMdd}-{sequence:0000}";
}
```

Poor:

```csharp
public sealed class CaseManager
{
    public void CreateCase() { }
    public void SaveToDatabase() { }
    public void SendEmail() { }
    public void RenderWindow() { }
}
```

## Open Closed Principle

Code should be open for extension but closed for uncontrolled modification.

Use policies, strategies or handlers when variation is expected.

## Liskov Substitution Principle

Derived types must not surprise callers. If a subtype cannot honour the base contract, the abstraction is wrong.

## Interface Segregation Principle

Prefer small, role-focused interfaces.

Good:

```csharp
public interface ICaseReader
{
    Task<CaseRecord?> GetAsync(CaseId id, CancellationToken cancellationToken);
}

public interface ICaseWriter
{
    Task SaveAsync(CaseRecord caseRecord, CancellationToken cancellationToken);
}
```

Avoid large interfaces that force implementers to depend on methods they do not need.

## Dependency Inversion Principle

High-level policy should not depend on low-level details.

Application services should depend on abstractions; infrastructure supplies implementations.

## SOLID Review Questions

* Does this class have more than one reason to change?
* Is this abstraction real or speculative?
* Can implementations be substituted safely?
* Is the interface too broad?
* Does business logic depend directly on infrastructure?
* Could this be tested without external systems?