136 articles filed under this topic.
Inflow is a modular monolith whose modules agree on their boundaries and disagree about everything inside them - a four-project onion next to a single feature-sliced assembly. Part 1 of a series reading the money-moving half of the estate.
Most repositories ship code and a README - this one ships four ADRs with a named approver, a context map, a domain message flow and a methodology poster. Part 1 of a series that reads the strategic half of DevMentors' GroupFlights.
A teaching repo that implements one airline-charter domain three ways on purpose - CRUD, CRUD-plus-rich, and Clean Architecture - and persists it three ways to match. Part 1 of a source-reading series.
Database-per-tenant, schema-per-tenant, or packed into a shared database? Kicking off a series on building a multi-tenant platform where one EF Core codebase supports all three isolation strategies behind a single control plane.
Every modular monolith promises you can extract a module later. Inflow has a branch where someone actually did it - one module lifted into its own process behind a gateway and a real broker. This series reads that branch line by line.
DevMentors' ModularMonolith sample packs three conference-system modules, a mini-framework and one deliberately broken contract into eighty-four C# files - opening a series that reads all of it, defects included.
Reading a repository one project at a time hides everything that lives in the edges between them - and in this estate the edges are where the interesting failures are.
Every modular monolith claims its modules are decoupled. Inflow proves it the only way that counts - by having no project reference between any two of them - and then has to build a whole mini-framework to make that survivable. Part 1 of a source-read through the shared layer.
Inflow ships an executable request collection - five .rest files, thirty-seven requests. On a fresh clone nine of them return a 2xx, and eight of those nine are in one file. This series reads the repository itself as the artefact.
DevMentors shipped Trill as nine microservice repos, then rebuilt the identical product as a modular monolith three months later - giving us a controlled experiment in architecture that almost never exists in public.
Lessons from migrating a multi-tier .NET Framework monolith to .NET microservices on Azure Kubernetes Service: what to split first, what to leave alone, and the manifests that hold it together.
A Christmas Day commit on an unfinished feature, three years of unactioned dependabot, a final fix by a stranger - and the estate's real lesson, which is about re-reading rather than writing.
A product whose entire interface is a YAML document, shipped in an image that document cannot enter - plus the resilience inventory of a gateway with retries and nothing else.
CI builds Release, where six extensions compile against NuGet instead of your working tree - and the only thing that notices is a project with no tests in it.
One commit reclaimed a clean package id and deleted the version prefix in the same breath - leaving two identities on the public feed with inverted version ordering and a csproj that cannot build the package it consumes.
A caller-identity feature added at 21:10, disabled at 22:31 and deleted four days later - and the residue is a gateway that carries no caller identity into a message at all.
Of eight JWT keys in the README's flagship example, four bind to nothing, three restate defaults and one has any effect - and the last edit to that README came ten minutes before the commit that invalidated it.
One YAML key turns an HTTP route into a message publisher - and between BasicPublish returning and the gateway writing 202 there is nothing at all.
Nothing in either host references an extension type, so nothing should load one - and the reason six packages are found anyway is a call five steps earlier in a fluent chain.
An int? sorted into a HashSet, no shipped config that sets it, and two middlewares whose relative position determines whether your production failures appear in Jaeger at all.
Two strings and two void methods buy you six shipping packages - and the list of things the interface never asks for is the more instructive half.
Reading a repository one project at a time hides everything that lives in the edges between them - and in this estate the edges are where the interesting failures are.
Inflow's last commit landed on 23 July 2022 and nothing in the repository says so. The retrospective on eleven parts of reading a teaching repo as an artefact - what it gets right, what it costs, and what four passes over one estate add up to.
Inflow is full of deliberate, defensible simplifications. One of them is explained in a code comment, and it is instantly legible as a teaching decision. The other seven are indistinguishable, on the evidence in the repository, from bugs.
Inflow throws at startup if a module's local copy of another module's event has changed shape. The rule the whole repository exists to demonstrate - that no module may reference another - is protected by nothing at all.
Inflow's .NET 6 upgrade touches 519 files. Run the diff with whitespace ignored and almost all of it is one Rider refactoring - and the three real changes, plus two design rewrites nobody announced, are hiding underneath it.
Inflow ships the same exercise twice, on two branches prepared eleven days apart from the same commit. They do not start from the same place, neither converges on master, and both carry a README describing components they have deleted.
One branch in Inflow carries five commits timestamped 11:56, 13:49, 14:11, 14:49 and 16:08 on a single Saturday. That is not a development history - it is a live teaching session committed as it happened, and it explains a defect on master.
Four articles of defects earn an audit. Inflow's README makes fifteen checkable claims and eleven of them hold - including the strongest one, checked edge by edge across all twenty project files. Here is the ledger, and why a short README is so hard to falsify.
Inflow's request collection contains a captioned request that grants full administrative permissions to an anonymous caller. The mechanism is four lines long, the documented happy path requires it, and the repository nowhere says it is on purpose - here is all of that, and the case for the defence.
GET /payments returns a 404 in Inflow's own root request file. The reason is not a typo - it is the Payments module exercising exactly the architectural freedom the README advertises, which makes this 404 the best evidence in the repository that the claim is true.
Getting money into a wallet in Inflow takes five HTTP requests and nine in-process reactions nobody documents. Reconstructing that path from source is the only way to get it - and every failure along it returns 204 No Content.
Inflow ships an executable request collection - five .rest files, thirty-seven requests. On a fresh clone nine of them return a 2xx, and eight of those nine are in one file. This series reads the repository itself as the artefact.
Eleven parts of reading one commit. Inflow's dependency-inversion boundary survived a real transport swap intact - and everything ambient that used to travel with a message did not. The retrospective, the ledger, and what I would take from it.
Inflow's transport seam is one method wide and genuinely transport-agnostic, but it has exactly one implementation and no default. A four-line Null Object and one if statement would have turned a fork in the road into a configuration flag.
The extracted Customers service ships one EF migration that creates three empty tables in a brand-new database. Nothing dual-writes, nothing backfills, nothing reconciles - and the only path that repopulates the service is events that have not happened yet.
