domain-decomposition-api-design-advisor

Identify domain boundaries and API contracts from vague product concepts.

14|1|Updated Mar 6, 2026
One-click install
npx skills add https://github.com/yalishevant/kotlin-backend-agent-skills --skill domain-decomposition-api-design-advisor-yalishevant
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-decomposition-api-design-advisor
Source: https://github.com/yalishevant/kotlin-backend-agent-skills/tree/main/.agents/skills/domain-decomposition-api-design-advisor
Command: npx skills add https://github.com/yalishevant/kotlin-backend-agent-skills --skill domain-decomposition-api-design-advisor-yalishevant

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Convert vague product intent into explicit technical boundaries and contracts that can survive implementation and change. Optimize for clear ownership, explicit invariants, and low coupling rather than premature microservice enthusiasm.

Core Features & Use Cases

  • Decomposition workflow: break the feature into use cases, identify core nouns, aggregates, and decision points; separate commands from queries as appropriate.
  • Boundary guidance: define whether the right boundary is a module, bounded context inside a modular monolith, or a separate service, while avoiding shared databases as a default pattern.
  • API design discipline: specify idempotency, versioning, error semantics, and data ownership before implementation.
  • ADR-style reasoning: capture options, rationale, and follow-up risks to guide evolution.

Quick Start

Use the domain-decomposition-api-design-advisor to decompose this feature and design bounded contexts and API contracts.

Frequently Asked Questions about domain-decomposition-api-design-advisor

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

FAQPage Schema
How do I define bounded contexts when decomposing a complex domain?

To define bounded contexts, break the feature into use cases, identify core nouns and aggregates, and separate commands from queries. This decomposition workflow clarifies domain boundaries and ownership while reducing system coupling.

How do I design API contracts for system redesigns with unclear boundaries?

Design API contracts by explicitly specifying idempotency, versioning, error semantics, and data ownership before implementation begins. This discipline ensures explicit technical boundaries that survive system redesigns and future changes.

When should I choose a modular monolith over separate services for domain decomposition?

Choose a modular monolith or bounded context inside it when boundaries are unclear, optimizing for clear ownership and explicit invariants. This approach avoids premature microservice enthusiasm and prevents shared databases as a default pattern.

What is the best way to capture architecture decisions for multi-team ownership?

Capture architecture decisions using ADR-style reasoning to document options, rationale, and follow-up risks. This approach ensures decision traceability and guides system evolution across multiple teams with clear ownership.

How do I convert vague product concepts into explicit technical boundaries?

Convert vague product concepts into explicit technical boundaries by identifying use cases and core nouns, then defining bounded contexts and API contracts. This workflow ensures boundary definition and compatibility planning for feature scoping.