What problem does it solve?
Rails teams frequently split monoliths incorrectly, creating distributed monoliths with the same tight coupling as the original but worse latency, or making bad cuts like entity-based "User Services" that become system-wide chokepoints. This Skill eliminates that risk by providing proven, senior-developer-backed guidance for safe, effective monolith decomposition.
Core Features & Use Cases
- Bounded context identification: Guides teams to split by business capability, not database entity, using team ownership, code churn analysis, and ubiquitous language mapping.
- Service contract definition: Provides templates for versioned public APIs and schema-validated domain events to ensure clear, backward-compatible service communication.
- Data ownership enforcement: Prevents shared databases and cross-service joins by mandating service-owned data with denormalized snapshots for historical accuracy.
- Distributed transaction handling: Implements saga patterns with compensating actions to replace cross-service database transactions without data inconsistency.
- Anti-pattern prevention: Explicitly blocks common mistakes like shared model libraries, synchronous fan-out, and notification-only services.
Use Case: A 50+ engineer Rails team that has outgrown its modular monolith can use this Skill to extract the first independent service (e.g., Billing or Identity) without introducing hidden coupling or operational debt.
Quick Start
Use the microservices-decomposition skill to map your Rails monolith's bounded contexts and define the first service boundary after confirming your team has answered yes to all gating questions in the when-NOT-to-use-microservices skill.
