skills.rest
haryelramalho
haryelramalhoCOMMUNITY
Explore all skills by this author →
Website𝕏@haryel_devGitHub

domain-modeling

Creates CONTEXT.md glossaries and ADR files documenting architectural decisions and vocabulary per bounded context.

Updated May 28, 2026
Search Tags:#architecture#domain modeling#adr#glossary#context map#ubiquitous language
One-click install
npx skills add https://github.com/haryelramalho/skills --skill domain-modeling-haryelramalho
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/haryelramalho/skills/tree/main/skills/community/domain-modeling
Command: npx skills add https://github.com/haryelramalho/skills --skill domain-modeling-haryelramalho

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps teams define and maintain a clear domain vocabulary, record important architectural decisions, and prevent confusing or inconsistent terminology from spreading through a codebase.

Core Features & Use Cases

  • Glossary building: Create and update a concise CONTEXT.md that defines project-specific terms and preferred language.
  • Decision recording: Capture hard-to-reverse architectural choices as short ADRs with context, rationale, and consequences.
  • Multi-context support: Use a CONTEXT-MAP.md when a repository contains several bounded contexts and keep each context’s vocabulary separate.
  • Use case: A team introduces a new bounded context, resolves ambiguous terms like customer versus user, and documents the chosen model so future contributors stay aligned.

Quick Start

Use the domain-modeling skill to review this repository’s terminology and add the missing context glossary or ADR entries.

Frequently Asked Questions about domain-modeling

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

FAQPage Schema
How do I maintain consistent domain terminology across a growing codebase?▼

Documenting architectural decisions uses short ADR files to capture context, rationale, and consequences for hard-to-reverse choices. This keeps trade-off-heavy design decisions traceable and prevents knowledge loss as the repository evolves.

How do I manage domain vocabulary when a repository contains multiple bounded contexts?▼

Managing domain vocabulary across multiple bounded contexts requires a CONTEXT-MAP.md file. This maps each context separately, keeping the ubiquitous language precise and preventing terminology overlaps or inconsistencies between different areas of the system.

What is the best way to record architectural decisions and trade-offs?▼

Recording architectural decisions as short ADR files is the best way to capture trade-offs. Each ADR documents the context, rationale, and consequences of a hard-to-reverse design choice, ensuring future contributors understand why a model was selected.

When do I need a context map versus a standard glossary for domain modeling?▼

You need a context map instead of a standard glossary when a repository contains several bounded contexts. A CONTEXT-MAP.md separates each context’s vocabulary, while a standard CONTEXT.md glossary works for a single context with evolving terminology.

Related Skills

Explore More Software Engineering Skills→
guilhermemarketingguilhermemarketing
59

domain-analysis

Identify subdomains and map bounded contexts across codebases.

Community
Advanced
JohannesKoningsJohannesKonings
9

domain-modeling

Standardize domain terminology and document architectural decisions in software projects.

Community
Intermediate
bflandevbflandev
1

use-case-to-technical-design

Transform reviewed use cases into Clean Architecture and DDD technical designs.

Community
Advanced
TheycallmehollaTheycallmeholla

connotation-cop

Audit terminology against a CONTEXT.md glossary and enforce ADR documentation.

Community
Intermediate