Skip to content
Keshwar White

Software architect · Author

Keshwar White

I design .NET systems that have to last, and I write about how to build them.

I've been developing software professionally since 2010. These days most of my time goes into architecture: Domain-Driven Design, Clean Architecture, and the decisions that keep a codebase easy to change years after it ships.

What I do

Software the next developer can understand

Good architecture isn't about how many patterns you can fit into a solution. It's about what the system will need six months from now, and who has to maintain it.

Software architecture

I design systems around the business they serve. That means boundaries that mean something, rules that live in one place, and a structure the next developer can follow without a tour guide.

Building products

I don't just draw diagrams. I build and ship software, from enterprise systems people use every working day to CashAscent, a personal finance product I designed and built end to end.

Writing and teaching

I explain why an approach exists before showing how to implement it. The goal isn't to make architecture look complicated. It's to make complicated architecture feel understandable.

Portrait of Keshwar White

About me

Understand how it works.Find out why it doesn't.Then figure out how to make it work better.

I grew up on Montserrat, taking apart televisions and stereos that people had thrown away, trying to understand why they stopped working. At nine I met DOS and Where in the World Is Carmen Sandiego?, and the machine quickly became more interesting than the game. The systems I work on now are a lot bigger. The instinct is the same.

The new book

Practical Domain-Driven Design with .NET

Domain-Driven Design, Clean Architecture, Vertical Slices, and SOLID in ASP.NET Core

This book teaches Domain-Driven Design, Clean Architecture, vertical slices, and the SOLID principles the second way, without making you wait years for it. It follows one example system, a multi-tenant student information system, from the first commit to an application that's ready to operate. One running system serves many school districts, and each district's data has to stay its own. So every pattern has to earn its place against realistic constraints.

Also by me: C# Cheat Sheet: The Keywords. Available in paperback on Amazon.

What you'll learn

  • Model business rules in a domain that protects itself.
  • Organize the application by use case with vertical slices.
  • Separate commands from queries, using EF Core where it helps and Dapper where it helps.
  • Keep every tenant's data apart by default, not by remembering to.
  • Authorize by capability instead of role name.
  • Make domain events reliable with an outbox, and prove all of it with tests at every layer.

Built on .NET 10 (LTS), ASP.NET Core Minimal APIs, Entity Framework Core, Dapper, SQL Server, xUnit.

Selected work

Things I've built

See the full portfolio
The CashAscent dashboard showing cash position, debt totals, and the next required payments.

Product

CashAscent

A personal finance app that turns income, bills, debts, buy-now-pay-later installments, reserves, and goals into a plan you can follow one paycheck at a time.

  • .NET 10
  • FastEndpoints
  • EF Core
  • Dapper
  • SQL Server
Visit cashascent.app(opens in a new tab)

Book

Practical Domain-Driven Design with .NET

Domain-Driven Design, Clean Architecture, vertical slices, and SOLID, taught on one realistic system from the first commit to an application that is ready to operate.

  • .NET 10 (LTS)
  • ASP.NET Core Minimal APIs
  • Entity Framework Core
  • Dapper
  • SQL Server
About the book
API · InfrastructureApplicationDomain

Professional work

Enterprise systems

Most of my day-to-day work is on internal enterprise .NET systems. The code stays private, but the kind of work doesn't.

  • .NET
  • ASP.NET Core
  • Angular
  • SQL Server
  • Microsoft Entra ID

Get in touch

Let's talk about software, architecture, or the book.

Whether it's a question about a chapter, an invitation to speak, or a design problem you're working through, I'd like to hear about it.