domain-modeling

Standardize domain terminology and document architectural decisions in software projects.

9|Updated Dec 1, 2025

Search Tags:#architecture #documentation #adr #glossary #domain-driven-design #ubiquitous-language

Ready to run

npx skills add https://github.com/JohannesKonings/tanstack-aws --skill domain-modeling-johanneskonings

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/JohannesKonings/tanstack-aws/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/JohannesKonings/tanstack-aws --skill domain-modeling-johanneskonings

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This skill resolves ambiguity in project terminology and ensures architectural decisions are documented, preventing technical debt caused by fuzzy language or undocumented trade-offs.

Core Features & Use Cases

Glossary Management: Maintains a canonical CONTEXT.md to define project-specific terms and eliminate overloaded vocabulary.
Architectural Decision Records (ADR): Provides a structured, lightweight framework for recording high-stakes design choices.
Use Case: When a team is debating whether to use the term "Client" or "Customer" across a new billing module, this skill forces a decision, updates the glossary, and ensures the choice is consistently applied.

Quick Start

Use the domain-modeling skill to define the term Invoice in our context and check if it conflicts with existing definitions.

Frequently Asked Questions about domain-modeling

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

FAQPage Schema

How do I standardize domain terminology and ubiquitous language across multiple bounded contexts?▼

Recording architectural decisions involves documenting high-stakes design choices and irreversible trade-offs. This skill provides a lightweight framework for creating Architectural Decision Records (ADRs) to prevent technical debt caused by undocumented design decisions.

What is the best way to resolve ambiguous domain terminology in a new software module?▼

Resolving ambiguous domain terminology requires standardizing definitions within a project context. This skill facilitates defining terms like Invoice, checks for conflicts with existing definitions, and updates the ubiquitous language glossary to eliminate overloaded vocabulary.

How does documenting architectural decisions prevent technical debt?▼

Documenting architectural decisions prevents technical debt by recording high-stakes design choices and irreversible trade-offs. This skill provides a structured framework for Architectural Decision Records (ADRs) to ensure design choices are consistently applied across teams.

Does this domain-driven design approach work for managing context maps between separate modules?▼

Managing context maps for domain-driven design ensures consistency across multiple bounded contexts. This skill standardizes domain terminology and architectural decision-making to maintain alignment and prevent fuzzy language between separate software modules.

When do I need an Architectural Decision Record for my software architecture?▼

An Architectural Decision Record is needed when making irreversible design trade-offs or high-stakes architectural choices. This skill provides a structured framework to document these decisions, preventing technical debt caused by undocumented design choices.