Software Engineer building stable, business-critical systems.

Unknown is a value

Problem

When a figure cannot be worked out from its sources, code tends to return a plausible number anyway. That number then ends up in charts and reports with nothing to show it was a guess.

Use case

Anyone building reports or dashboards on incomplete records, for example a salary comparison where one source includes pension and another never says.

What this demo shows

Open maybe.ts and salary.ts. A calculation returns either a known value or unknown with a required reason, and TypeScript will not let the caller use the number until it has handled the unknown case. Look at change(): it refuses on two separate grounds, a missing pension basis and different weekly hours.

Result, not exception

Problem

If "this vehicle is already booked" and "the database is down" are thrown as the same kind of exception, every caller writes the same catch block and the two cases get mixed up.

Use case

A team building a .NET web API that needs honest status codes: expected business failures are handled by the caller, infrastructure failures go to one central handler.

What this demo shows

In BookingEndpoint.cs a booking comes back as a Result. A clash maps to 409 and inverted dates to 400, while a dropped connection still throws and becomes a 500. The handler has no try/catch at all.

Result, not exception

Problem

If "this vehicle is already booked" and "the database is down" are thrown as the same kind of exception, every caller writes the same catch block and the two cases get mixed up.

Use case

A team building a .NET web API that needs honest status codes: expected business failures are handled by the caller, infrastructure failures go to one central handler.

What this demo shows

In BookingEndpoint.cs a booking comes back as a Result. A clash maps to 409 and inverted dates to 400, while a dropped connection still throws and becomes a 500. The handler has no try/catch at all.

Result, not exception

Problem

If "this vehicle is already booked" and "the database is down" are thrown as the same kind of exception, every caller writes the same catch block and the two cases get mixed up.

Use case

A team building a .NET web API that needs honest status codes: expected business failures are handled by the caller, infrastructure failures go to one central handler.

What this demo shows

In BookingEndpoint.cs a booking comes back as a Result. A clash maps to 409 and inverted dates to 400, while a dropped connection still throws and becomes a 500. The handler has no try/catch at all.

Result, not exception

Problem

If "this vehicle is already booked" and "the database is down" are thrown as the same kind of exception, every caller writes the same catch block and the two cases get mixed up.

Use case

A team building a .NET web API that needs honest status codes: expected business failures are handled by the caller, infrastructure failures go to one central handler.

What this demo shows

In BookingEndpoint.cs a booking comes back as a Result. A clash maps to 409 and inverted dates to 400, while a dropped connection still throws and becomes a 500. The handler has no try/catch at all.

Result, not exception

Problem

If "this vehicle is already booked" and "the database is down" are thrown as the same kind of exception, every caller writes the same catch block and the two cases get mixed up.

Use case

A team building a .NET web API that needs honest status codes: expected business failures are handled by the caller, infrastructure failures go to one central handler.

What this demo shows

In BookingEndpoint.cs a booking comes back as a Result. A clash maps to 409 and inverted dates to 400, while a dropped connection still throws and becomes a 500. The handler has no try/catch at all.

Unknown is a value

Problem

When a figure cannot be worked out from its sources, code tends to return a plausible number anyway. That number then ends up in charts and reports with nothing to show it was a guess.

Use case

Anyone building reports or dashboards on incomplete records, for example a salary comparison where one source includes pension and another never says.

What this demo shows

Open maybe.ts and salary.ts. A calculation returns either a known value or unknown with a required reason, and TypeScript will not let the caller use the number until it has handled the unknown case. Look at change(): it refuses on two separate grounds, a missing pension basis and different weekly hours.

Read model apart from write

Problem

When the same entities serve both the business rules and the screens, a summary page ends up loading several aggregates and building rows in a loop, and changing the screen puts the rules at risk.

Use case

A Spring application where one screen needs a flat, joined view (here an account summary) while money transfers must follow strict rules inside a single transaction.

What this demo shows

Compare the two files. AccountSummaryQuery.java returns a plain record from one SQL query, with no entities. TransferService.java enforces the transfer rules and never mentions the screen. Worth noticing: accounts are locked in id order to avoid deadlocks, and there is no second database or event bus.

Read model apart from write

Problem

When the same entities serve both the business rules and the screens, a summary page ends up loading several aggregates and building rows in a loop, and changing the screen puts the rules at risk.

Use case

A Spring application where one screen needs a flat, joined view (here an account summary) while money transfers must follow strict rules inside a single transaction.

What this demo shows

Compare the two files. AccountSummaryQuery.java returns a plain record from one SQL query, with no entities. TransferService.java enforces the transfer rules and never mentions the screen. Worth noticing: accounts are locked in id order to avoid deadlocks, and there is no second database or event bus.

Result, not exception

Problem

If "this vehicle is already booked" and "the database is down" are thrown as the same kind of exception, every caller writes the same catch block and the two cases get mixed up.

Use case

A team building a .NET web API that needs honest status codes: expected business failures are handled by the caller, infrastructure failures go to one central handler.

What this demo shows

In BookingEndpoint.cs a booking comes back as a Result. A clash maps to 409 and inverted dates to 400, while a dropped connection still throws and becomes a 500. The handler has no try/catch at all.

Money as a value object

Problem

Floats lose fractions of a krone, nothing stops kroner from being added to euros, and splitting an amount three ways quietly loses a unit.

Use case

Any system that handles prices, invoices or payouts, where amounts must add up exactly and currencies must never mix.

What this demo shows

Money.php keeps amounts as whole minor units (øre, cents) with the currency inside the object. Adding two different currencies throws, and allocate() splits 100 into 34, 33 and 33 so the parts always sum to the whole. Every operation returns a new object.

Read model apart from write

Problem

When the same entities serve both the business rules and the screens, a summary page ends up loading several aggregates and building rows in a loop, and changing the screen puts the rules at risk.

Use case

A Spring application where one screen needs a flat, joined view (here an account summary) while money transfers must follow strict rules inside a single transaction.

What this demo shows

Compare the two files. AccountSummaryQuery.java returns a plain record from one SQL query, with no entities. TransferService.java enforces the transfer rules and never mentions the screen. Worth noticing: accounts are locked in id order to avoid deadlocks, and there is no second database or event bus.

A ratchet gate

Problem

Turning on a lint rule in a codebase that already breaks it thousands of times leaves two bad options: block every build, or settle for warnings nobody acts on.

Use case

A team adopting a new rule in an existing codebase that wants new code to follow it from day one and old code to improve over time.

What this demo shows

Invoke-RatchetGate.ps1 reads an ESLint JSON report, counts violations per rule against a baseline committed to the repository, and fails only when a count goes up. The baseline is only ever lowered automatically; raising it takes a commit a reviewer can see.