A real inter-module messaging sample — CritterCrush deliberately isn't it

[jeremydmiller]

From the CritterCrush review (2026-09-06): CritterCrush stays a single-module event-sourced sample — its DetectMutualMatch automation is same-module event forwarding, and collapsing its endpoint/handler pairs (#13 follow-up work) removes the last bus-visible commands. That's the right teaching shape for what it covers, and it means the repo still lacks a sample whose point is messaging between modules.

What that sample should demonstrate (the things CritterCrush deliberately doesn't):

• Two or more modules with real boundaries, communicating through versioned integration messages — not shared types
• Durable local queues vs. an external transport, and when each is right
• MultipleHandlerBehavior.Separated actually earning its keep: two modules reacting independently to one event, with independent retry policies
• MessageIdentity.IdAndDestination under a real fan-out
• Tracked-session integration tests proving the cross-module cascade end to end

Existing samples brush against this (EcommerceModularMonolith, MeetingGroupMonolith) but as ports; this one would be designed around the messaging story from scratch — possibly as CritterCrush's own later chapters (Notifications reacting to MutualMatchDetected is the natural seam the model already hotspots) or as a fresh sample.

[jeremydmiller]

Parked here from the CritterCrush review (A2): when this sample demonstrates the split shape — an endpoint cascading a bus-visible command (see bobcat#218 for how the model designates that) — the translating endpoint's response semantics are part of the lesson: it answers before the handler runs, so it should return 202-Accepted-with-Location semantics, not CreationResponse's 201. The collapsed default doesn't have this problem; only the split does, which is why the worked example belongs here.