lowy

Identify module boundaries that separate sequence and activity volatility.

Updated Apr 26, 2026

Search Tags:#design #architecture #volatility #module-boundaries #lowy #parnas

Ready to run

npx skills add https://github.com/juspay/ci --skill lowy-juspay

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: lowy
Source: https://github.com/juspay/ci/tree/main/.claude/skills/lowy
Command: npx skills add https://github.com/juspay/ci --skill lowy-juspay

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Juval Lowy's volatility-based decomposition provides a principled way to evaluate architecture by asking whether module boundaries encase axes of change rather than simply group related functionality.

Core Features & Use Cases

Identifies and separates two independent axes of change: sequence volatility (order of steps) and activity volatility (how activities are performed).
Encourages stable interfaces and reduced blast radius by encapsulating volatile aspects behind orchestrators (Managers) and engines.
Supports architecture reviews and boundary decisions across systems undergoing change, scaling, or domain evolution.

Quick Start

Reframe current module boundaries around volatility axes and map likely changes to stable interfaces.

Frequently Asked Questions about lowy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I identify module boundaries that encapsulate volatility instead of functional grouping?▼

Volatility-based decomposition separates sequence volatility (workflow orchestration order) from activity volatility (how each step is performed) across modules. This approach establishes stable interfaces and assesses blast radius for change scenarios to isolate axes of change during architecture reviews.

When should I apply volatility-based decomposition during architecture reviews?▼

Apply volatility-based decomposition during architecture reviews when systems undergo change, scaling, or domain evolution. It separates sequence volatility from activity volatility across modules, establishing stable interfaces to encase axes of change and minimize the blast radius of modifications.

What is the difference between sequence volatility and activity volatility in software design?▼

Sequence volatility refers to the order of steps in workflow orchestration, while activity volatility concerns how each individual step is performed. Volatility-based decomposition separates these independent axes of change into different modules to establish stable interfaces and reduce blast radius.

How do I assess blast radius for change scenarios using volatility-driven boundaries?▼

Assess blast radius by mapping likely change scenarios to volatility-driven module boundaries and stable interfaces. Encapsulating volatile aspects behind orchestrators and engines isolates the impact of modifications and prevents changes in one axis from cascading across unrelated services.

Can I use volatility-based decomposition for systems undergoing domain evolution?▼

Yes, volatility-based decomposition supports architecture reviews and boundary decisions across systems undergoing domain evolution. Aligning naming with volatility-driven boundaries and separating sequence from activity volatility establishes stable interfaces that encase axes of change effectively.