.NET on Viklund

Types as Proof

Fri, 06 Nov 2026 11:36:00 +0200

Only the agent who’s assigned to a ticket may reply to it. The obvious way to enforce that is a check before the reply:

if (!IsAssignedTo(ticketId, agentId))
 throw new NotAssignedException();

// later: trusts that someone checked
ticket.Reply(content, agentId, now);

This works until the next use case forgets the check. The check returns a bool, and the answer is thrown away. When Reply runs, it gets an AgentId that may or may not have been checked, and nothing in the types tells you which.

Bridges Ask, Events Tell

Fri, 06 Nov 2026 11:35:00 +0200

The first version of this backend had one project that was allowed to know about every module. All the translation between modules lived there, which sounded tidy: one seam, one place to look. It ended up seeing every project and referencing everything, and it was hard to maintain and easy to get wrong. About three months in, we removed it.

What replaced it is much stricter about what each project can see, and it comes down to two moves:

Ports and Adapters Without Exceptions

Fri, 06 Nov 2026 11:34:00 +0200

Someone needs to load a ticket. They already have its id as a Guid, so they add an overload to the port, just this once:

public interface IForLoadingTickets
{
 Task<Ticket?> LoadAsync(TicketId id, CancellationToken ct);

 // just this once…
 Task<Ticket?> LoadAsync(Guid id, CancellationToken ct);
}

It compiles, and every unit test still passes. The build goes red anyway:

$ dotnet test tests/Architecture

failed DrivenPortsArchitectureTests.Driven_ports_should_never_accept_a_guid_parameter
 Driven ports should never accept a guid as a parameter. Offending types:
 Tickets.Application.Ports.Driven.IForLoadingTickets

The backend from the previous post is built this way. Its ports and adapters are rules the build enforces, with no exceptions, not even for plain CRUD. This post covers the layout, how it got there, and what it costs.

Four Models of One Person

Fri, 06 Nov 2026 11:33:00 +0200

In the customer service system I’ve been building at work, a support agent is four different things. To authentication, they’re a user who signs in and has roles. To the module that knows the people, they’re a profile with a name and a team. To the module that hands out work, they’re a ticket handler, someone who can be given tickets to work on. And to the module that owns the conversation, they only matter as someone who may reply and who wrote a message.