api-designer

Convert DMML domain models into OpenAPI 3.1 specifications with REST endpoints.

12|Updated Mar 7, 2026
One-click install
npx skills add https://github.com/mardenneubert/ddd-meets-genai --skill api-designer-mardenneubert
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-designer
Source: https://github.com/mardenneubert/ddd-meets-genai/tree/main/skills/api-designer
Command: npx skills add https://github.com/mardenneubert/ddd-meets-genai --skill api-designer-mardenneubert

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires pyyaml, and includes scripts (resource) and references (resource) components.

What problem does it solve?

Convert a DMML domain model into a complete OpenAPI 3.1 specification.

Core Features & Use Cases

  • Maps DMML bounded contexts to OpenAPI tags and boundary endpoints (POST for commands, GET for queries).
  • Generates schemas for value objects, entities, and domain events, and wires them to operations.
  • Documents invariants and preconditions as standard error responses.
  • Supports draft elements via an x-draft extension in operations when appropriate.

Quick Start

Run the API Designer on your DMML document to generate an OpenAPI 3.1 specification.

Frequently Asked Questions about api-designer

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

FAQPage Schema
How do I generate an OpenAPI 3.1 specification from a DMML domain model?

To generate an OpenAPI 3.1 specification from a DMML domain model, run the API Designer on your DMML document. It automatically maps bounded contexts to tags, commands to POST endpoints, and read models to GET endpoints.

How are DMML bounded contexts and aggregates mapped to REST endpoints?

DMML bounded contexts map to OpenAPI tags and boundary endpoints, while aggregates define the structure. Commands are mapped to POST endpoints and read models are mapped to GET endpoints to expose domain capabilities as REST operations.

Does generating OpenAPI from DMML automatically document domain invariants and errors?

Generating OpenAPI from DMML automatically documents invariants and preconditions as standard error responses. It also generates schemas for value objects, entities, and domain events, wiring them directly to the relevant operations.

What's the best way to handle draft elements in an OpenAPI specification derived from domain-driven design?

For draft elements in an OpenAPI specification derived from domain-driven design, the conversion process supports them via an x-draft extension in operations when appropriate, ensuring incomplete domain capabilities are properly flagged.

Do I need pyyaml installed to convert DMML to an OpenAPI 3.1 spec?

Yes, you need pyyaml installed to convert DMML to an OpenAPI 3.1 spec. This dependency is required to parse and process the YAML-based DMML documents before mapping them to the OpenAPI 3.1 specification structure.