Newest first, grouped by year. Search or filter by topic.
Inflow's inbox writes a row only after the handler succeeds, which makes its own duplicate-check predicate dead code and its name wrong. It is a good Idempotent Receiver with a one-hour memory, a decorator that resolves from the wrong provider, and an orphaned brace pair.
Two booleans govern Inflow's messaging spine. Taking their product gives four behaviours - one shipped and working, two working differently, and one that throws a NullReferenceException every second forever because the component that would prevent it only exists in another cell.
Inflow ships a complete transactional outbox - table, poller, cleanup jobs, type registry - and one CreateScope() call means the outbox row commits on a different DbContext from the state change it is supposed to be atomic with.
Inflow registers every handler by assembly scan and then wraps them in decorators. Those two techniques are incompatible unless something tells the scanner to skip the decorators - and in this codebase that something is a marker attribute with no tests and no comment explaining what it prevents.
Inflow carries request identity across its async message boundary in a static AsyncLocal. The line that populates it uses null-coalescing assignment inside a long-lived loop, so every message after the first runs under the first one's correlation id, trace id and user.
Inflow's message broker is eighty-eight lines with a three-way branch, backed by an unbounded channel and a single background reader. Reading it shows where the delivery guarantee actually is - and that on shutdown, whatever is still queued is discarded without a log line.
Inflow's boot-time contract verifier is excellent and almost unused. A census of every consumer-side type copy in the estate shows four protected and fourteen not - and the two failure modes are a startup crash and a silently null property.
Inflow isolates modules by serialising every message to JSON bytes and deserialising it into the receiver's own type - once per receiver. It is the Message Translator done well, and the byte array in the signature tells you exactly which transport it was built for.
Inflow lets each module own a private copy of every event it consumes, then type-checks those copies against the producer at application start. It is consumer-driven contract testing with no broker, no schema registry and about 280 lines - and the check is weaker than the ceremony suggests.
One method in Inflow returns the third segment of a type's namespace, lower-cased. Four subsystems route on that string, and nothing anywhere validates it - a namespace rename is a silent behavioural change across the estate.
Inflow has no subscribe call and no topic string. A module receives an event by declaring a class with the same simple name, and a single attribute decides whether the delivery is allowed - with a cache that changes the decision, not just its speed.
Inflow's host knows nothing about its five modules - it finds them by scanning DLL filenames and reflecting for an interface. Reading the loader shows why the whole estate is that small, and where a missing settings file silently deletes a module.
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 has nine tests, all in one module, and the most interesting one asserts a defect as if it were the specification. The honest retrospective on five modules, four architectures and what the estate actually teaches.
Inflow's one real saga has four compensation methods and no message that can ever trigger them. Its state lives in memory, its ordering rests on an undocumented property of a background service, and its failure mode is a denied bonus recorded as success.
Inflow's withdrawal flow is a three-module round trip with a compensating branch and no saga class. The correlation between the halves is a magic string declared three times and a JSON blob written by hand on one side and deserialised on the other.
Locking a customer flips a flag in three of the four modules that hold one. Wallets has Lock and Unlock methods on its Owner entity and nothing in the estate ever calls them - so the module that moves money is the module that never hears.
A single Guid minted at sign-up becomes a user, a customer, a payments customer, a wallet owner and a saga id - four Postgres schemas, five field names, zero foreign keys and nothing that declares the equality.
Wallets is four projects, Payments is one, and the same author wrote both in the same week. Three claims are usually made for the extra assemblies - one is true and verifiable in XML, one is weaker than it looks, and one is provably false.
Wallets abstracts its queries behind a storage interface that returns aggregates and maps in memory. Payments injects the DbContext and projects in SQL. On the read path the layered module is the slower and more coupled one.
Inflow models money as an Amount that wraps a bare decimal and a Currency that lives beside it on the entity. The two never travel together, nothing rounds, and the column is unconstrained numeric.
Inflow's aggregate root increments its Version at most once per instance lifetime. As a concurrency token that is correct; as a version number it is a lie - and the one unit test that touches it documents the latch instead of catching it.
Inflow's Wallet guards its transfers behind a private HashSet and then exposes a public setter for it. Assigning an empty list zeroes any balance with no exception, no version bump and no trace - and Entity Framework never needed the setter.
Each half of an Inflow transfer stores a referenceId in its metadata. On both legs that reference is the leg's own id - so the two halves of a transfer cannot be joined from the data they persist.
Wallet.TransferFunds mutates a second aggregate root inside the first one's method - the textbook DDD violation, committed for a good reason. The reason survives the domain layer and does not survive the handler.
