Writing
Functional Acceptance Testing at the Boundary
Functional acceptance tests verify complete outcomes through the assembled system. Correct arrangements, deep assertions, and controlled observations support release confidence.
Topic
Architectural Patterns
Recurring structures for system responsibilities and boundaries, including Domain Facades, Service Locators, Gateways, Data Managers, and Configuration Providers.
22 pages
Writing
One Order, Every Obligation
One ordering scenario verifies the caller result, stored lines, fulfillment, and confirmation. Follow its complete C# test, independent observations, and accumulated failure reports.
Writing
Questions About Functional Acceptance Testing at the Boundary
Boundary testing questions concern evidence, isolation, failures, and release confidence. Compare the practice with mocks, TDD, generated checks, formal models, and production observation.
Writing
Refactoring and Adopting Boundary Testing
A stable Domain Facade lets acceptance scenarios and assertions survive internal refactoring. Adapt test support behind unchanged observations and adopt complete boundary tests feature by feature.
Writing
Refusals, Failures, and Work Still Owed
Failure timing determines what an order still owes. Verify refusal, real transaction rollback, post-commit action failures, and accepted effects whose completion could not be recorded.
Writing
Testing the Service Interface
Interface tests verify wire conversion and exception translation at their owning boundaries. Controller Hooks, middleware checks, and hosted HTTP scenarios complement domain acceptance.
Writing
The Test Mediator and the Transport Spy
A Test Mediator and transport spy control delivery and expose observations while production gateways run. Capture email content, script retries, and measure bounded response reads.
Writing
Prefer Composition Over Inheritance
Composition keeps a configuration provider's capabilities limited to what its project needs. The refactor uses self-contained settings providers, a shallow base, and restrained reuse.
Writing
Abstraction in Software Design, with Examples
Give callers domain operations while collections and gateways own the details: service orchestration, model mapping and translation of recognized failures into domain exceptions.
Writing
Validating Formal Arguments? No Thank You!
Validate and clean data at the front and back doors; skip checks on internal formal arguments. Immutable DTOs preserve trust, one exception reports all errors, and black box tests exercise the doors.
Writing
Programming to Exceptions, Part 2: Diagnostics and Boundaries
Specific exceptions preserve failure meaning, causes, and context. A shallow C# hierarchy, Gateway translation, and middleware enrichment carry diagnostic records across service boundaries.
Writing
Programming to Exceptions, Part 1: Method Contracts and Failure
Method contracts let callers rely on completed work and let failures propagate. C# examples distinguish retrieval from search, validate domain entry points, and assign handling to its owner.
Writing
Interfaces? No Thank You!
C# interfaces do not inherently create contracts or loose coupling. Composition handles hierarchy conflicts; capability interfaces and structural typing let consumers see only what they need.
Writing
The Configuration Provider: Roles and Responsibilities
A Configuration Provider hides the source and returns validated, typed settings. Useful exceptions and composed settings providers keep configuration rules in one place.
Writing
The Gateway Design Pattern: Roles and Responsibilities
A Gateway presents business operations, translates service models and transforms failures into domain exceptions, keeping external service details behind one boundary.
Writing
Clean Abstractions Around Libraries
A library boundary owns the application's contract even when its terms match the library's. It contains provider types, validation, failures, and configuration, and keeps replacement possible.
Chapter
Architecture Layers in C#
Structure communicates intent: strict layers from Domain Facade to Gateway, internal by default with a public surface the compiler enforces, and folder depth that marks each class's level of abstraction.
Chapter
Architecture Layers in Python
Structure communicates intent: strict layers from Domain Facade to Gateway, a public surface declared in the boundary __init__.py, and folder depth that marks each class's level of abstraction.
PWI
Architecture with Intent
The Domain Facade exposes business operations while internal classes call one level down. Managers orchestrate workflows and own configuration and service boundaries.
Writing
The Purpose and function of a Data Access Layer
A Data Access Layer isolates business logic from the logical data model through domain-specific methods, stored procedures, and results shaped for the business layer.
Writing
ASP.NET MVC Framework Design Problems
ASP.NET MVC's indirect access to views spreads responsibilities across controllers and templates. ViewData, child actions, and typed view instances frame the critique.
Writing
ASP.NET MVC3 - Razor View Engine
Razor makes C# mixed with HTML easier to read through its @ syntax, code blocks, layouts, and sections. Worked templates show the output and the limits of view responsibilities.