القائمة
Models a business in its own language. Use when the domain has real business rules to capture.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/athola/claude-night-market --skill architecture-paradigm-domain-drivenيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Turn hunches into accepted results: worthiness score, evidence bar, research-to-rules. Use when vetting ideas. Not for QA; use night-market-validation-and-qa.
Generates and self-executes a diff-derived test plan for a PR. Use when validating PR changes before merge. Do not use for code review; use sanctum:pr-review.
Curate the web-capture index. Use when the capture backlog grows, captures sit unprocessed at seedling/pending, or to surface stored research during work.
عرض SKILL.md
استنادا إلى تصنيف SOC المهني
| name | architecture-paradigm-domain-driven |
| role | library |
| description | Models a business in its own language. Use when the domain has real business rules to capture. |
| alwaysApply | false |
| category | architectural-pattern |
| tags | ["architecture","domain-driven-design","ubiquitous-language","bounded-context","anti-ceremony"] |
| dependencies | [] |
| tools | [] |
| usage_patterns | ["paradigm-implementation","domain-modeling","legacy-decomposition","adr-support"] |
| complexity | intermediate |
| model_hint | standard |
| estimated_tokens | 1400 |
Design for the future, build for now.
DDD is modeling a business in the business's own language. The goal is not to avoid structure. It is to avoid structure you cannot back out of, and to defer structure you do not yet need.
Ubiquitous language, bounded contexts, and a model built by talking to the people who do the work. The measure of a domain model is whether a person in the business would recognize their own job in it.
Clean Architecture. Mandatory layering. A mapper between every tier. A count of design patterns applied before the first line of business logic is written.
These are DDD-adjacent choices. Each has its own justification, and none of them is entailed by DDD. Wanting to decouple an API from the domain is a good reason to add a DTO. "This is what DDD requires" is not, because it does not.
The building blocks are not the point, and this is not the repo's opinion. Evans said so himself, ten years after the book, about the book:
"things like the entities and value objects [..] [People] come away thinking that that's really the core of DDD, whereas, in fact, it's really not."
"I really think that the way I arranged the book gives people the wrong emphasis, so that's the biggest part of what I do is rearrange those things."
Source: SE-Radio Episode 226, "Eric Evans on Domain-Driven Design at 10 Years" (video). Quotes as transcribed by The Core of Domain-Driven Design, which also cites his DDD Europe 2016 keynote criticizing the "over-emphasis on building blocks."
What the core actually is: discovering subdomains and drawing bounded contexts, in language the business already speaks. Entities, value objects, and aggregates are how a model reaches code once it exists. They are the translation, not the thing being translated.
Read the rest of this skill in that light. Every mechanism below is optional machinery serving a model you found by talking to people.
Once a domain exists, create the data store and one concrete data object. Pass that object from the repository into the business layer. At the start of a project, pass it out to the view as well.
That is a legitimate starting state, not technical debt. One object moving through every layer is the cheapest thing that can work, and it is the shape the divergence protocol below is designed to split.
The DTO arrives at the moment of divergence, not in anticipation of it.
Trigger: the view's response shape must hold for contract reasons while the domain model needs to change.
Move: the old data object becomes the view DTO. The new domain object gains a translation into it. Where fields differ, a copy constructor maps them, in either direction as needed.
That is the whole mechanism. It works because the starting state (one shared object) is the same shape as the ending state's DTO, so the split costs one rename and one translation function. This is why "we might need a DTO later" is not a reason to build one now: later is cheap.
Ordered by cost:
Option 3 carries a cost worth stating plainly: inheritance couples the layers. Changing the base changes every context at once, which is the opposite of the flexibility the divergence protocol buys. It also feeds straight into the boundary hazard below. Reach for it when duplication is the larger present pain, and reach for it knowing what it trades away.
Do not reuse a data type across a network or other IO boundary without validating that you are not sharing something you should not.
This is the one non-negotiable constraint in this skill. Everything else here can be deferred, dropped, or added later. This cannot.
Option 3 is where it bites hardest: a field added to a shared base class appears silently in every serialized representation that inherits it, including the one crossing the wire. The convenience is real and so is the leak.
When two or more systems exchange commands over a network and do not deploy atomically, a versioned request DTO lets you introduce a new shape while continuing to serve the old one, and migrate the systems one at a time. Without it, any change to the command shape requires every system to update simultaneously, which fails the moment one update fails or one release waits on an app store, an IT department, or another team.
That is a deployment constraint, not a DDD principle. Name it as such when you justify the DTO, so the next reader knows which force put it there and when it can go.
Never in one pass. A refactor that tries to do every layer at once does not land. Per domain, in order:
Then repeat for the next domain. Keep the implementation simple until a need for more appears.
.claude/rules/ceremony-requires-need.md and the
ceremony-audit lens in Skill(pensive:architecture-review). A mapper
whose fields are all 1:1 copies is a mapper with no job.These vocabulary items name the concrete tools and abstractions that show
up when the paradigm is implemented. They are not required dependencies and
they are not part of the skill's tools: frontmatter (which is reserved
for Claude Code tool restrictions). Use this list to disambiguate during
architecture discussions.
ubiquitous-language-glossary: the term list the business and the code
both use, maintained as a first-class artifactcontext-map: names each bounded context and the relationships between
them, including where one term changes meaningcopy-constructor: the translation introduced at the moment of
divergence, mapping fields between a domain object and its view DTO