Index
All Topics
Every subject on the site, with a description of what it covers. Tags come from a controlled vocabulary, so the build fails on one that is not declared.
Architecture5
How a system is divided into layers, where each responsibility belongs, and what may legitimately depend on what.
Naming4
Choosing names that state what a thing is, and keeping those names stable as a value moves through a system.
Method Design8
Visibility, return contracts, abstraction levels, and the difference between a method that acts and one that answers.
Class Design10
Separating behavior from state, deciding what may be inherited, and keeping types honest about what they hold.
Testing4
Which layer proves what, how tests are arranged, and what a passing test is actually evidence of.
Acceptance Testing3
Exercising a system through its front door as a black box, with attention to where test data comes from and what keeps a scenario true over time.
Error Handling5
Treating failure as a designed path: validation at boundaries, exception translation, and what a caught exception obliges you to do.
Data Access1
Reaching a store without letting its shape leak upward. Language-independent guidance, currently illustrated in Python.
LLM Systems1
Designing processors, engines, and gateways that call language models, and keeping that machinery testable.
Python7
Material specific to Python, or illustrated with Python examples.
C#16
Material specific to C#, or illustrated with C# examples.
TypeScript0
Material specific to TypeScript, including this site’s own build.
AI-Assisted Development3
Working with coding agents: what to delegate, how to review the result, and where the failure modes cluster.
Verification3
Establishing that required work actually happened, rather than accepting a confident report that it did. Coverage, completion, and what evidence supports a claim.
Agent Orchestration1
Coordinating multiple model workers: who decides what, what each one may see, what runs concurrently, and what stops a run.
Code Review3
Turning written guidance into rules a reviewer can apply consistently, by machine or by hand.
Public Surface6
The set of types a component exposes to its callers. Everything a caller can receive, pass or must catch belongs on it, and everything else stays internal, so the interior can change without breaking anyone.
Levels of Abstraction2
Arranging classes by altitude, so each level states what happens and delegates how to the level below. A class’s depth in the folder tree shows its level, and dependencies run one level down.
Service Interface Layer2
The thin host layer, such as a web API, CLI, worker or cloud function, that connects the outside world to a system. It translates transport input and forwards it to the domain, which must not depend on the host.
Design Patterns14
Named, reusable solutions to recurring design problems, from the classic catalogue and from this body of work, such as the Domain Facade, the Service Locator and the Gateway.
Domain Facade3
The single public entry point to a domain. It holds no logic of its own, forwards each business operation to a Manager, and hides every internal layer from callers.
Service Locator4
A narrow factory that creates only what must be swappable, such as configuration, loggers and transport handlers, so tests can substitute them. Only the Manager uses it, and only during construction.
Configuration Provider7
A typed wrapper over raw configuration that reads and validates settings eagerly and returns typed settings objects. Only the Manager uses it, and it passes values downstream, never the provider.
Gateway Pattern6
A domain-owned boundary to an external service. It presents business-shaped operations and models, and keeps provider types, resource models and failure translation behind it as one deletable unit.
Data Manager4
The component that owns a domain’s whole conversation with a data store. It presents business-shaped operations and keeps store technology, command construction and fault translation behind its seam.
Strategy Pattern3
Selecting one of several interchangeable behaviors through a common role.
Delegates1
Using C# delegates to pass behavior and compare that choice with named strategy classes.
Composition Over Inheritance4
Building capabilities from collaborating objects while keeping inheritance narrow and deliberate.
Dependency Injection1
Passing collaborators into objects and deciding which dependencies callers should control.
Factory Pattern3
Creating the right implementation behind a focused construction boundary.
Factory Method1
A creation hook on a consumer base class that subclasses override to choose a dependency from another class family.
Polymorphism2
Using a shared contract to work with different implementations without making callers name their concrete types.
Library Boundaries1
Contracts that let a system request capabilities in its own terms while containing a library’s calls, types, and failure conventions.
Model Design1
Defining data types so required fields, genuine absence, and distinct variants are clear to consumers.
Template Method1
Defining an operation in a base type while subclasses provide selected steps.
Extension Methods1
C# methods called as if they belong to a type, and their effect on discoverability and meaning.
Data Transfer Objects1
Immutable data carriers that keep state separate from the behavior operating on it.
Type Casting1
Choosing casts and type checks according to whether a mismatch is expected or a defect.
Mocking1
Replacing collaborators in tests and evaluating the effect on coupling and regression coverage.
Test Driven Development1
Using tests to establish behavior before implementation and preserving them through design changes.
Interfaces1
C# interface roles, their costs, and when a consumer needs a narrow capability.
Interface Segregation1
Presenting each consumer with only the operations it needs.
Boundary Validation2
Checking untrusted input and output at system boundaries while keeping internal flows clear.
Jev1
TypeSafe AI’s System One model for typed judgments about supplied text. Choice, Score, and Noul support bounded semantic decisions.
Model Evaluation1
Measuring model decisions on representative labeled cases, including error costs, calibration, thresholds, abstention, and performance after changes.
Speculative Fan-Out1
Asking independent questions about shared state in one request, including answers that some later routes will not use.
Confidence-Gated Routing1
Using a model’s answer and tested confidence thresholds to choose between automatic action, another process, and human review.
Composite Scoring1
Scoring separate semantic dimensions and combining them with explicit weights to support a decision.
Intent Routing1
Classifying a request’s intent to choose a handler, such as ordinary code, a specialist model, or a person.