docs: 增强 DDD 设计证明门禁

--delete-branch

Author: LiTeXz

skills/df-ddd-event-storming-design/SKILL.md

@@ -239,6 +239,78 @@ Do not regenerate the whole model unless the user asks or the existing model is
 - Treat CQRS as a modeling perspective: commands change business state through the domain model; queries are satisfied by read models.
 - Read models should record their information sources, but query needs must not create domain events by themselves. A read-model-only field can come from current-state lookup, query-side joins, technical projection inputs, external sources, or accepted event payloads.
 - Iterate when commands, events, aggregates, or read models do not explain each other.
+- Treat commands, events, aggregate state, aggregate methods, and read-model fields as design claims that need proof. If the proof is only "the table/API/page has this field", downgrade the item to discovery material until a business rule or consumer proves it belongs.
+
+## Design Proof Gates
+
+Use these gates before finalizing commands, events, aggregates, aggregate methods, or read models. They are mandatory when reviewing or persisting a model.
+
+### Event Admission Gate
+
+For every accepted domain event, prove:
+
+- business fact: what happened in past tense
+- producer: actor/external system -> command/fact input -> aggregate/process -> event
+- non-query consumer: actor option, command-side rule, policy/process, aggregate relationship, lifecycle, or downstream business capability affected by the fact
+- read-model impact, if any: which projection changes and which fields change
+
+Keep brainstormed but rejected events only in `候选事件池与筛选`, not in the formal `领域事件清单` or aggregate event list. If an item only repairs a projection, display, report, cache, operation log, or troubleshooting view, reject it as a domain event and record the alternative source.
+
+### Command Granularity Gate
+
+Design commands from actor intent or external fact input boundaries, not from permutations of possible events.
+
+- One command may produce multiple events when those outcomes belong to the same actor intent and consistency boundary.
+- Do not create separate commands merely because different event combinations are possible.
+- Do not create one "apply/sync/update all" command unless the initiating actor or external system is actually submitting one authoritative fact package and the aggregate can make the decision coherently.
+- When a command can produce multiple events, explain why the events are the result of one business decision instead of independent actions.
+
+### Aggregate State Necessity Gate
+
+For every aggregate state item or property, prove at least one direct use:
+
+- a command/business method reads it to decide whether an action is allowed
+- an invariant or uniqueness rule depends on it
+- it affects event production, rejection, splitting, or payload enrichment
+- it represents identity, lifecycle, ownership, parentage, or another state needed to enforce consistency
+
+If no current or confirmed future business method uses the state item, remove it from the aggregate design. Reclassify it as read-model data, persistence metadata, audit/log material, synchronization metadata, or unresolved discovery material.
+
+### Identity And Uniqueness Gate
+
+Model identity and uniqueness by actor/source, not as one generic "name/code must be unique" rule.
+
+For each uniqueness rule, record:
+
+- who relies on it: human actor, import operator, external master system, downstream system, or policy
+- identity fields and scope: tenant, company, parent, external ID, code, name, effective date, or other boundary
+- enforcement timing: command-side strong consistency, external acceptance check, deferred reconciliation, or query-only detection
+- conflict result: reject, correct, merge, override, ignore, or log-only
+
+If different actors use different identity rules, keep them as separate rules even when they touch the same subject.
+
+### Lifecycle Removal Gate
+
+For delete, unregister, close, archive, disable, or decommission behavior, prove:
+
+- the exact business meaning of removal
+- the real blocking business fact, not just indirect structural children
+- whether historical references remain valid
+- whether restoration exists as a real business capability; if not, do not add restore commands or events
+- which downstream actor, policy, rule, or read model changes after removal
+
+### Read Model Source Gate
+
+For every read-model field, record its source:
+
+- accepted domain event payload or projection
+- current-state lookup from command-side persistence
+- query-side join
+- technical projection input
+- audit/log/troubleshooting source
+- external read source
+
+Do not add a domain event only to populate a read-model field. A missing read-model field is a sourcing question first and a domain-event gap only when a non-query business consumer exists.
 
 ## Traceability Rules
 
@@ -534,13 +606,19 @@ Before finalizing, check:
 - Every important event has an affected actor, subject, command-side rule, policy/process, aggregate, or downstream business relationship.
 - Current-domain state-changing events are published by aggregates unless a clear exception is recorded.
 - Every command has the information it needs from command fields plus aggregate state/history.
+- Every command is justified by actor intent or an external fact input boundary, not by an arbitrary event-combination permutation.
+- If one command may publish multiple events, those events are explained as outcomes of one business decision inside one consistency boundary.
 - Meaningful command outcomes are represented as events.
 - Generic events such as `信息已变更` have been replaced by specific facts or explicitly justified.
+- Rejected candidate events are not retained in accepted event catalogs, aggregate event lists, or implementation-alignment lists.
 - Every read model records whether each field comes from accepted events, current-state lookup, query-side joins, technical projection inputs, enriched payloads, or external read sources.
 - Every read-model-only field is marked as query-side data, technical projection input, current-state lookup, audit/log material, or external-source data instead of being promoted to a domain event.
 - Policies do not hide aggregate invariants.
 - Domain services do not become procedural service layers.
 - Aggregates are derived from behavior, rules, identity, lifecycle, and invariants, not tables, CRUD resources, or noun lists.
+- Every aggregate property is directly used by at least one command/business method, invariant, uniqueness rule, event production decision, lifecycle decision, or consistency relationship.
+- Human-maintained identity rules and external-system identity rules are separated when they use different scopes or keys.
+- Removal/decommission rules identify the real blocking business fact, historical-reference behavior, and downstream consequence.
 - Aggregates are neither too large nor too fragmented.
 - Query needs do not pollute aggregate state.
 
@@ -560,6 +638,11 @@ Refuse or correct these patterns:
 - Treating external master-data sync as a simple upsert when ordering, dependency, failure, or conflict resolution has business meaning.
 - Creating domain events for technical actions the business does not care about.
 - Creating domain events only because a read model, page, report, cache, or projection needs a field refreshed.
+- Keeping rejected candidate events in final event lists, aggregate files, or implementation checklists.
+- Creating command permutations from possible event combinations instead of actor intent or external fact input.
+- Adding "source type", "current status", "description", display names, or other fields to aggregate state when no aggregate method or invariant uses them.
+- Collapsing different identity rules into one generic uniqueness statement when human actors and upstream systems use different scopes or keys.
+- Adding restore behavior because it is technically possible when no business capability exists.
 - Putting report/page/query fields into aggregates for convenience.
 - Putting most business rules into command handlers, application services, listeners, repositories, or policies.
 - Splitting bounded contexts before understanding the current problem domain.

skills/df-ddd-event-storming-design/references/anti-patterns.md

@@ -14,6 +14,12 @@
 - Upsert sync modeling: treat external master-data synchronization as a simple create/update when the business cares about dependency ordering, conflict handling, missing parent records, retries, or failure status.
 - Read model leakage: add page/report fields to aggregate state only because a query needs them.
 - Projection-driven event: create a domain event only because a read model, page, report, cache, or projection needs a field refreshed.
+- Rejected candidate leakage: keep brainstormed-but-rejected events in final event catalogs, aggregate event lists, or implementation-alignment checklists.
+- Command permutation explosion: create commands from possible event combinations rather than actor intent, external fact input, and consistency boundary.
+- Unused aggregate state: add properties to an aggregate because a table, API, projection, or UI has them even though no aggregate method, invariant, uniqueness rule, lifecycle rule, or event decision uses them.
+- Generic uniqueness rule: collapse actor-specific identity rules into a single "name/code must be unique" statement when human maintenance and upstream systems use different scopes, keys, or conflict handling.
+- Invented restoration: add restore commands/events only because deletion is modeled, without a confirmed restoration business capability.
+- Indirect removal guard: block removal by structural children rather than the real business fact that matters to the domain.
 - Framework-shaped domain: treat controllers, DTOs, repositories, or packages as the domain model.
 - Unproduced event: keep a domain event without a command, policy, process, or external fact that can produce it.
 - Unexplained read source: define a read model field without identifying whether it comes from accepted events, current-state lookup, query-side joins, technical projection input, enriched payloads, audit/log data, external sources, or a confirmed domain-event gap.

skills/df-ddd-event-storming-design/scripts/examples/proof_gate_violations.md

@@ -0,0 +1,21 @@
+# 问题域边界
+
+后台目录管理。
+
+# 领域事件清单
+
+- 名称已修订，不进入领域事件，只用于展示字段。
+- 外部事实已拒绝，不进入领域事件，排查走日志。
+
+# 命令清单
+
+- 按事件组合创建命令：名称变更加状态变更命令、名称变更加除册命令。
+
+# 聚合设计
+
+- 聚合属性：来源类型、当前状态、描述。
+- 这些属性目前无业务方法使用，当前只是展示和同步排查。
+
+# 完整性检查
+
+- 名称不能重复。

skills/df-ddd-event-storming-design/scripts/run-design-examples.test.ts

@@ -50,6 +50,11 @@ const CASES = [
 		file: "artifact_flooding.md",
 		expectErrors: true,
 	},
+	{
+		name: "proof_gate_violations",
+		file: "proof_gate_violations.md",
+		expectErrors: true,
+	},
 ];
 
 describe("DDD Design Validation", () => {

skills/df-ddd-event-storming-design/scripts/validate-ddd-design.ts

@@ -36,6 +36,20 @@ const SMELLS: Record<string, string[]> = {
 		"(Company|Dept|Department|Position|Employee)(Created|Updated|Deleted|Edited)Event",
 		"(公司|部门|岗位|员工).*(新增|修改|删除|编辑).*事件",
 	],
+	rejected_candidate_leakage: [
+		"(不进入领域事件|拒绝|淘汰|降级|候选事件).{0,80}(领域事件清单|聚合事件|事件列表|最终事件)",
+	],
+	command_permutation: [
+		"(事件组合|排列组合|不同组合|每种组合).{0,80}(命令|cmd|command)",
+		"(命令|cmd|command).{0,80}(事件组合|排列组合|不同组合|每种组合)",
+	],
+	unused_aggregate_state: [
+		"(聚合属性|聚合状态|状态字段|属性清单)[\\s\\S]*(来源类型|sourceType|当前状态|currentStatus|描述|description)[\\s\\S]*(未使用|无业务方法|仅展示|只展示)",
+		"(来源类型|sourceType|当前状态|currentStatus|描述|description).{0,80}(聚合属性|聚合状态)",
+	],
+	generic_uniqueness: [
+		"^(?![\\s\\S]*(范围|scope|租户|公司|父级|上游|人工|来源|actor))[\\s\\S]*(名称|编码|name|code).{0,20}(不能重复|唯一|冲突)",
+	],
 };
 
 const REQUIRED_SECTIONS = [