This was generated by AI during triage.
From architecture review candidate #4 (recommendation: Speculative). Captured for triage.
Problem
A leaky seam: every feature calls into the notifications module directly, and notifications in turn must know about all ~20 entity types to resolve owners and types. The coupling is bidirectional.
Proposed solution
Domains emit typed events (engagement.liked, message.created); a notifications subscriber translates events into rows. Per the deletion-test heuristic, one adapter today = a hypothetical seam — revisit only if a second event consumer appears (digests, activity feed). At that point the seam becomes real.
Why speculative
There is currently only one consumer of these events (notifications), so the event layer would be indirection without a second client to justify it. File it so the idea isn't lost, but it should likely wait for a real second consumer.
Relationships
From architecture review candidate #4 (recommendation: Speculative). Captured for triage.
Problem
A leaky seam: every feature calls into the
notificationsmodule directly, andnotificationsin turn must know about all ~20 entity types to resolve owners and types. The coupling is bidirectional.Proposed solution
Domains emit typed events (
engagement.liked,message.created); a notifications subscriber translates events into rows. Per the deletion-test heuristic, one adapter today = a hypothetical seam — revisit only if a second event consumer appears (digests, activity feed). At that point the seam becomes real.Why speculative
There is currently only one consumer of these events (notifications), so the event layer would be indirection without a second client to justify it. File it so the idea isn't lost, but it should likely wait for a real second consumer.
Relationships