사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/yonatankarp/software-design-skills --skill ddd-ubiquitous-language시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
One-line summary
Establish a single vocabulary shared by domain experts, developers, code, and tests — within one bounded context.
When to use this skill
- A new project starting to model a domain.
- Persistent terminology drift between business and engineering.
- The code's names don't match how domain experts talk.
- Translation tables sit between conversation and code ("when the business says 'invoice', we mean
BillingDocument").
When NOT to use this skill
- Code-level pattern questions → delegate to tactical pattern skills.
- Cross-context terminology translation → route to
ddd-context-mapping. - Naming conventions for variables and functions in general → that is a code-style concern, not DDD.
Core content
A ubiquitous language is the shared, precise vocabulary that domain experts and engineers use to discuss a model — and that appears verbatim in the code, the tests, the database, and the UI. It is not a glossary the team agrees to consult; it is the language they actually speak and write.
How to grow one. Listen to domain experts and capture their phrases without paraphrasing. When the experts say "settle a payment", the code has a method called settle, not processPayment. When experts disagree about a term, push them to reconcile — that disagreement is hiding a real distinction (often two concepts crammed into one word).
Per bounded context. A ubiquitous language is consistent within one bounded context. Two contexts may use the same word with different meanings, and that is fine — context mapping handles the translation. The mistake is trying to enforce one global enterprise-wide language.
The reading-aloud test. Take a piece of code (a method body, a test name, a class hierarchy) and read it aloud to a domain expert. If they recognize what it does, the language is working. If they ask "what does that mean?", the language has drifted from the model.
Decision heuristics
- Apply inside a bounded context. Resist the urge to unify language across an enterprise.
- Push back when developers invent names ("Manager", "Helper", "Processor") instead of asking experts what to call the concept.
- Kill synonyms aggressively. "Customer", "Client", and "Account" should not all coexist meaning the same thing in one context.
Anti-patterns
- Developers inventing names because asking the expert "takes too long".
- Tolerating synonyms because each team prefers a different one.
- Translation tables between conversation and code — a sign that the model is misaligned.
- Maintaining a glossary as a separate document instead of the code being the glossary.
See also
ddd-bounded-context— one language per context; the boundary makes a coherent language possible.ddd-design— language is the first deliverable of any design session.ddd-context-mapping— translating language across contexts.
References
- Evans, Domain-Driven Design (2003), Ch. 2 (Communication and the Use of Language).
