Splitting a Bounded Context, With the ADR Attached
ADR 04 extracts the reservation-change process out of Sales, lists ten steps and two recommendations - and nine of the ten steps are traceable to real code.
Newest first, grouped by year. Search or filter by topic.
ADR 04 extracts the reservation-change process out of Sales, lists ten steps and two recommendations - and nine of the ten steps are traceable to real code.
ADR 04 names one risk in prose - changing a reservation on stale information - and the table built to mitigate it has no version, no timestamp and no concurrency check.
One published type from the Communication module is mapped as an owned entity into TimeManagement's schema - so adding a field to your own contract now needs a migration you do not own.
Seven of thirteen published integration events in GroupFlights have exactly one consumer - the module that published them - and one has none at all.
ADR 01 chose a verbal ban on illegal project references over an automated architecture test - and the ban held perfectly, in an estate whose database boundary has no enforcement at all.
Seven contract projects are the estate's entire cross-module surface - and one misplaced marker interface drags the dispatcher framework into two of them by copy-paste.
Three of the ten contexts on the context map have no code behind them - and reading the absences carefully separates a design placeholder from a forgotten promise.
A repeatable twenty-minute method for deriving a real context map from the project graph and the event subscriptions - then diffing it against the one on the wall.
ADR 03 declares six relationship patterns across ten bounded contexts and gives a reason for each - read on its own terms, before any code is checked against it.
GroupFlights picks a different application architecture per module on purpose - and the module nobody singled out turns out to hold the only real aggregate in 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.
Which of ModularMonolith's three modules could become a service tomorrow, what blocks the other two, and the hardening bill the sample never pays - a retrospective on the modular monolith as a station, not a destination.
Conferences and Speakers disagree on layout, naming, id policy, exception visibility, mapping style and route constraints - plus a 200 that returns nothing and a broker that threw NotImplementedException for four months. The honest ledger.
One middleware turns ConferenceNotFoundException into the wire code conference_not_found via Humanizer - a naming convention promoted to API contract, with a 400-versus-404 tension and Error-level logs it never resolved.
ModularMonolith's entities are public-setter data bags, its one immutability rule is a fixup with a comment, and its hardest domain question is asked in a comment and answered by nothing - a reading of domain modelling by annotation.
Conferences registers in-memory and EF repositories for the same interfaces and lets last-registration-wins pick - a live lesson in DI as strategy selector, dead registrations as fossils, and a no-op UpdateAsync nobody deleted.
A single boolean in appsettings decides whether ModularMonolith's events run inside your HTTP request or on a background pump - and each setting fails differently. Delivery semantics, read honestly from a ternary.
One Postgres database, one schema per module, and entity configurations that are all empty bodies - what ModularMonolith's data layer declares about future service boundaries, and what its migrations quietly gave away.
The last commit of ModularMonolith renames Name to ConferenceName in the subscriber's copy of its one integration event - and the JSON translator has delivered null into that field ever since. Anatomy of a silent contract break.
ModularMonolith builds its message broker from System.Threading.Channels and one BackgroundService - a textbook Message Channel and Event-Driven Consumer in miniature, with every missing enterprise-integration pattern visible by its absence.
ModularMonolith routes events between modules by class name and converts them by JSON round-trip - a one-line Message Translator that lets modules share contracts without sharing types, at a price the next part collects.
The last commit of ModularMonolith moves one line of Startup from first to last - and the whole cross-module event system depends on it. Assembly scanning, throwaway service providers and migrations inside ConfigureServices.
Every module in ModularMonolith plugs in through the same Add/Use extension pair - a recipe small enough to memorise, complete enough to be a mini-framework, and visible even where a module registers nothing at all.
ModularMonolith makes every controller internal and teaches MVC to find them anyway - compile-time module isolation from one feature provider, an InternalsVisibleTo chain, and the one place the wall has a hole.
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.