Skip to main content

Microservice Granularity Optimizer

Software ArchitectureFundamentals of Software Architecture

Right-size microservice boundaries using granularity disintegrators (forces to split: service scope, code volatility, scalability, fault tolerance, security, extensibility) and integrators (forces to combine: database transactions, workflow/choreography coupling, shared code, data relationships). Includes choreography vs orchestration selection and the saga pattern for distributed transactions. Use this skill whenever the user is splitting a monolith into microservices, deciding how fine-grained services should be, experiencing too many inter-service calls or latency from over-splitting, dealing with distributed transaction problems across microservices, choosing between choreography and orchestration for service communication, implementing the saga pattern, debugging a distributed monolith, or evaluating whether services should be merged or split further -- even if they don't use the exact phrase "microservice granularity."

Install

1. Add marketplace
› /plugin marketplace add bookforge-ai/bookforge-skills
2. Install plugin
› /plugin install fundamentals-of-software-architecture@bookforge-skills
3. Use the skill
› /microservice-granularity-optimizer
CC-BY-SA · Open sourceGitHub

Source Book

Fundamentals of Software Architecture cover

Fundamentals of Software Architecture

Mark Richards, Neal Ford

Edit on GitHub

More from Fundamentals of Software Architecture

Software Architecture

Architect Control Calibrator

Determine the appropriate level of architect control over a development team using a quantitative 5-factor scoring model (-100 to +100 scale). Use this skill whenever the user asks how much they should be involved in a team's decisions, how hands-on or hands-off to be as an architect, how to calibrate their leadership style, whether they are micromanaging developers, whether they should give the team more autonomy, or any question about architect involvement level, team oversight, or technical leadership balance — even if they don't explicitly say "control." Also triggers when the user describes team dysfunction symptoms like merge conflicts increasing, nobody speaking up in meetings, or tasks falling through cracks.

Software Architecture

Architect Role Assessor

Evaluate whether a software architect is fulfilling the 8 core expectations of the role and assess their technical breadth vs depth balance using the knowledge pyramid. Use this skill whenever the user asks what a software architect should be doing, questions whether they are performing the architect role correctly, wants to assess their own or someone else's architect performance, describes symptoms of role dysfunction (spending too much time coding, not attending stakeholder meetings, only recommending technologies they know, avoiding decisions), asks about transitioning from developer to architect, or encounters the Frozen Caveman anti-pattern where past experiences irrationally drive current decisions — even if they don't explicitly say "architect role" or "expectations."

Software Architecture

Architecture Characteristics Identifier

Systematically identify, categorize, and prioritize architecture characteristics (quality attributes / -ilities) from requirements, domain concerns, and stakeholder input. Use this skill whenever the user is starting a new project, defining architecture requirements, translating business needs into technical characteristics, asking "what quality attributes matter?", figuring out nonfunctional requirements, or evaluating what -ilities to optimize for — even if they don't explicitly say "architecture characteristics."

Software Architecture

Architecture Decision Record Creator

Create structured Architecture Decision Records (ADRs) with 7 sections to document architecture decisions with full justification. Use this skill whenever the user has made or needs to make an architecture decision, wants to document why a technical choice was made, is choosing between technologies or patterns, needs to create an ADR, or is experiencing repeated debates about past decisions — even if they don't explicitly mention "ADR" or "architecture decision record."