Component Collaboration Architecture

Use this skill to decide how application parts should talk to each other and where behavior, data, state, and side effects should live.

When to use

Trigger for work like:

• deciding whether one class should call several collaborators directly
• deciding whether to emit one event and let multiple consumers react
• removing proxy, listener, handler, manager, or service chains that only forward
• finding who owns state, validation, lifecycle, retries, side effects, or recovery
• replacing shared registries, broad mutable state, or god coordinators with clearer owners
• designing local projections, read models, event-fed caches, or explicit query boundaries
• reviewing event-heavy, command-heavy, observer-heavy, or callback-heavy code for ownership
• breaking dependency cycles where a primitive/source-of-truth domain is reaching into downstream cleanup, projection, notification, or cache maintenance
• deciding whether a state transition should publish a domain fact for downstream owners to consume

Do not use this skill for ordinary naming, small-function cleanup, Kotlin idioms, Spring wiring, or Cucumber structure unless the main issue is collaboration shape or ownership boundaries.