Where do Clean Architecture and design patterns sit when the dependency is an LLM?

Most of what I read showed how to direct integrate. New client, send a prompt, deal with LLM and print the text. What was absent what is about extending the system? you drop the same call into a real service and the usual questions show up. Where does the client live? What happens when you leave the local models on your machine and move to Anthropic or Azure OpenAI? How do you test a use case without a live endpoint? Who owns the prompt: the controller, the handler, or a string in a helper?

We already have answers for this. In Clean Architecture an external system sits behind a port. The domain does not know SQL Server from Postgres. It should not know OllamaSharp from IChatClient either. Some chat APIs take a session id and keep the transcript. Some want the full history on every request. Either way, conversation state, instructions, and retrieved text are application concerns. The model is infrastructure.

This article is how I started mapping the usual .NET habits onto that dependency: a chat port so use cases do not take a vendor SDK, a builder where prompts are not interpolated in the handler, and decorators so cache and telemetry are not copied into every call. I am not writing about training models. I am writing about keeping AI features maintainable in a .NET system. core principles which should take care about to build a solid foundations system.

Encapsulation as a critical point

An LLM is not special infrastructure. Treat it like a database, a payment gateway, or an SMS provider:

• it lives outside your domain

• it can fail, throttle, or change shape

• you talk to it through abstractions

• your business rules stay in C#, not in the model

If you drop vendor clients straight into controllers, you will pay for it later. Same mistake as scattering SQL everywhere.

Encapsulate the LLM behind a clear contract. Consumers ask for a result. They should not know the provider or the SDK.

A minimal mental model for .NET developers

You do not need ML theory. You need enough context to make design decisions.

From a software point of view, an LLM is a non-deterministic text engine:

• Memory: some APIs take a session or conversation id and keep the transcript for you. Others expect you to send the full history on every call. Either way that state is a conversation store (yours or the vendor's), not the model itself. A session id is not a reason to skip a port.

• Non-deterministic: the same prompt can yield a different completion. Do not treat the raw string as a domain fact.

• Tokens: cost and rate limits are measured in tokens, not characters. Prompt size, history windows, and retrieved context are budget decisions.

You will not implement a tokenizer. You will design prompts, history, and session handling around these limits.

Focus on what changes your design: where conversation state lives, and a token budget you must respect.

Put AI in the infrastructure layer

LLMs talk to the outside world. They are not the source of business truth.

The application layer never knows which provider answered. It depends on IChatService. The domain depends on neither the application layer nor IChatService.

• Chat is a use-case concern. Domain stays business rules.

Same idea as hiding SQL behind a repository. If use cases take vendor SDKs, switching providers or writing tests becomes a rewrite.

Today you may run Ollama locally. Tomorrow the product may need Anthropic, Gemini, or Azure OpenAI for scale, compliance, or quality. If every use case references OllamaApiClient, that switch is a rewrite. If the provider lives in one infrastructure class behind IChatService, the change is registration and configuration. Use cases, prompt building, and domain rules stay the same. Tests mock the port. No model required.

Microsoft.Extensions.AI gives you IChatClient. That is still the SDK. Your use cases should not take it. They take IChatService, a small interface you own. ChatService is the adapter: it takes your prompt, calls the SDK, and returns text your app can use.

ChatUseCase  =>  IChatService  =>  ChatService  =>  IChatClient

public interface IChatService
{
    Task<ChatAnswer> GetResponseAsync(ChatPrompt prompt, CancellationToken ct);
}

public sealed class ChatService(IChatClient client) : IChatService
{
    public async Task<ChatAnswer> GetResponseAsync(ChatPrompt prompt, CancellationToken ct)
    {
        var response = await client.GetResponseAsync(prompt.ToMessages(), cancellationToken: ct);
        return new ChatAnswer(response.Text);
    }
}

Register the adapter. To switch providers you change CreateVendorClient. The use case does not change.

builder.Services.AddChatClient(CreateVendorClient(builder.Configuration));
builder.Services.AddScoped<IChatService, ChatService>();

Depend on interfaces, not vendor SDKs.

How prompt building maps to a design pattern

A production prompt is not an interpolated string in a use case. It is a structured object:

• system instructions

• user profile or tenant data

• conversation history (user and assistant turns)

• retrieved documents, if any

• the current user message

String concatenation in the use case makes prompts hard to test, hard to version, and easy to break.

History must keep assistant turns as assistant. If you send the model's old replies as user messages, the next answer gets worse.

That is the Builder pattern. The use case names the pieces. Build() owns order: system, retrieved context, history, then the user message.

var prompt = new PromptBuilder()
                        .WithSystemInstructions(rules)
                        .WithConversationHistory(history)
                        .WithRetrievedContext(chunks)
                        .WithUserMessage(query)
                        .Build();

Create a new builder per request. Do not inject a mutable builder as a singleton. Leftover history from the previous call will leak into the next one.

ChatPrompt is an ordered list of turns. You can log it, snapshot it in a test, and send it through the port. The builder has a slot for retrieved text. It does not do retrieval.

The use case names the pieces, then calls the port:

public sealed class ChatUseCase(IChatService chat)
{
    public Task<ChatAnswer> ExecuteAsync(ChatRequest request, CancellationToken ct)
    {
        var prompt = new PromptBuilder()
                        .WithSystemInstructions(request.SystemInstructions)
                        .WithConversationHistory(request.History)
                        .WithUserMessage(request.UserQuery)
                        .Build();

        return chat.GetResponseAsync(prompt, ct);
    }
}

Cross-cutting concerns with Decorator

Tomorrow you need caching, Then telemetry, Then rate limiting. You should not edit every model call.

Here is the ideal use of the Decorator pattern, or the middleware style from Microsoft.Extensions.AI:

IChatClient
    => cache
        => telemetry
            => rate limiter
                => vendor client

Builder builds the prompt. The port sends it. Cache, telemetry, and rate limits wrap the call. You do not edit ChatUseCase or ChatService when you add cache. You wrap the client at registration:

builder.Services.AddChatClient(CreateVendorClient(builder.Configuration))
                .UseDistributedCache()
                .UseOpenTelemetry();

UseDistributedCache and UseOpenTelemetry are decorators. Each one is still an IChatClient. ChatService keeps taking IChatClient. The use case does not know cache exists.

Conclusion

AI does not replace architecture. It stresses it. Calling an LLM is development; Designing a system that stays maintainable around an LLM is software engineering. Put the model behind an infrastructure port. Compose prompts with a builder instead of string soup in use cases. Stack cache and telemetry with decorators so those concerns do not leak into use cases. Keep the provider in one registration so switching does not rewrite the application.

Get the boundaries right first. The fancy codes are easier to rebuild than a tangled production codebase.