domain-modeling

Refines domain terminology and records architectural decisions in CONTEXT.md and ADR documentation.

Updated Aug 26, 2024

Search Tags:#software design #domain modeling #adr #context map #ubiquitous language #architecture decisions

Ready to run

npx skills add https://github.com/FabienDehopre/my-netatmo-24 --skill domain-modeling-fabiendehopre

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/FabienDehopre/my-netatmo-24/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/FabienDehopre/my-netatmo-24 --skill domain-modeling-fabiendehopre

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps teams reduce ambiguity in software design by establishing precise domain terminology, validating concepts, and recording important architectural decisions.

Core Features & Use Cases

Domain Language Refinement: Challenges vague terms, defines canonical vocabulary, and maintains a shared understanding of business concepts.
Context Documentation: Creates and updates CONTEXT.md files with focused domain terms while keeping implementation details separate.
Architectural Decision Records: Captures significant trade-offs and long-lived decisions using lightweight ADR documentation when appropriate.

Quick Start

Use the domain-modeling skill to review the current project terminology and update the domain context with clearer definitions.

Frequently Asked Questions about domain-modeling

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

FAQPage Schema

How do I refine ubiquitous language and reduce ambiguity in software domain modeling?▼

Refining ubiquitous language in domain modeling involves challenging vague terms and defining a canonical vocabulary to establish a shared understanding of business concepts. This process clarifies domain terminology and separates implementation details from core business logic.

What is the best way to document architectural decisions and trade-offs in software engineering?▼

Documenting architectural decisions is best achieved by creating lightweight Architecture Decision Records that capture significant trade-offs and long-lived choices. This approach records context and consequences without unnecessary implementation details, ensuring decisions remain accessible over time.

How do I maintain a CONTEXT.md file for documenting bounded contexts?▼

Maintaining a CONTEXT.md file for bounded contexts requires recording focused domain terms and definitions while explicitly keeping implementation details separate. This creates a clear glossary that validates concepts and preserves a shared understanding of the domain boundaries.

When do I need to record architecture trade-offs using ADR documentation?▼

You need to record architecture trade-offs using ADR documentation when making significant, long-lived decisions that impact the software's structure. Capturing these trade-offs provides context for future teams and prevents cyclical debates over previously settled design choices.

Does domain modeling require separating implementation details from the context glossary?▼

Yes, effective domain modeling requires separating implementation details from the context glossary. Maintaining a CONTEXT.md file with focused domain terms ensures that architectural decisions and business vocabulary remain distinct from low-level code structure.