dflow-sdd-ddd 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +209 -0
- package/bin/dflow.js +72 -0
- package/lib/init.js +1206 -0
- package/package.json +42 -0
- package/templates/core/scaffolding/CLAUDE-md-snippet.md +168 -0
- package/templates/core/scaffolding/Git-principles-gitflow.md +350 -0
- package/templates/core/scaffolding/Git-principles-trunk.md +375 -0
- package/templates/core/scaffolding/_conventions.md +175 -0
- package/templates/core/scaffolding/_overview.md +165 -0
- package/templates/core/scaffolding/architecture-decisions-README.md +34 -0
- package/templates/core/templates/CLAUDE.md +172 -0
- package/templates/core/templates/_index.md +118 -0
- package/templates/core/templates/aggregate-design.md +58 -0
- package/templates/core/templates/behavior.md +62 -0
- package/templates/core/templates/context-definition.md +64 -0
- package/templates/core/templates/context-map.md +25 -0
- package/templates/core/templates/events.md +19 -0
- package/templates/core/templates/glossary.md +15 -0
- package/templates/core/templates/lightweight-spec.md +82 -0
- package/templates/core/templates/models.md +47 -0
- package/templates/core/templates/phase-spec.md +195 -0
- package/templates/core/templates/rules.md +24 -0
- package/templates/core/templates/tech-debt.md +15 -0
- package/templates/webforms/scaffolding/CLAUDE-md-snippet.md +167 -0
- package/templates/webforms/scaffolding/Git-principles-gitflow.md +333 -0
- package/templates/webforms/scaffolding/Git-principles-trunk.md +316 -0
- package/templates/webforms/scaffolding/_conventions.md +139 -0
- package/templates/webforms/scaffolding/_overview.md +109 -0
- package/templates/webforms/templates/CLAUDE.md +157 -0
- package/templates/webforms/templates/_index.md +110 -0
- package/templates/webforms/templates/behavior.md +58 -0
- package/templates/webforms/templates/context-definition.md +57 -0
- package/templates/webforms/templates/context-map.md +25 -0
- package/templates/webforms/templates/glossary.md +15 -0
- package/templates/webforms/templates/lightweight-spec.md +82 -0
- package/templates/webforms/templates/models.md +39 -0
- package/templates/webforms/templates/phase-spec.md +187 -0
- package/templates/webforms/templates/rules.md +24 -0
- package/templates/webforms/templates/tech-debt.md +15 -0
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
<!-- Template maintained by Dflow. See proposals/PROPOSAL-013 for origin. -->
|
|
2
|
+
|
|
3
|
+
# Context Map
|
|
4
|
+
|
|
5
|
+
> Bounded context relationship map for the Core architecture.
|
|
6
|
+
|
|
7
|
+
## Contexts
|
|
8
|
+
|
|
9
|
+
| Bounded Context | Responsibility | Owner / Team | Primary Module | Notes |
|
|
10
|
+
|---|---|---|---|---|
|
|
11
|
+
| {Context name} | {業務責任} | {owner} | `{module/project}` | {optional notes} |
|
|
12
|
+
|
|
13
|
+
## Relationships
|
|
14
|
+
|
|
15
|
+
| Upstream | Downstream | Relationship Type | Published Language | ACL | Events |
|
|
16
|
+
|---|---|---|---|---|---|
|
|
17
|
+
| {Upstream context} | {Downstream context} | {Customer/Supplier, Conformist, ACL, Shared Kernel, etc.} | {shared terms / contract} | {Yes/No + location} | {event names or n/a} |
|
|
18
|
+
|
|
19
|
+
## Integration Notes
|
|
20
|
+
|
|
21
|
+
- {跨 context 的資料流、contract、ACL 或 integration event 設計}
|
|
22
|
+
|
|
23
|
+
## Open Questions
|
|
24
|
+
|
|
25
|
+
- {尚未釐清的 context 邊界或 upstream/downstream 關係}
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
<!-- Template maintained by Dflow. See proposals/PROPOSAL-013 for origin. -->
|
|
2
|
+
|
|
3
|
+
# Domain Events
|
|
4
|
+
|
|
5
|
+
> Domain event catalog for one bounded context.
|
|
6
|
+
|
|
7
|
+
## Event Catalog
|
|
8
|
+
|
|
9
|
+
| Event name | Producer | Trigger | Payload | Consumers | Delivery expectation |
|
|
10
|
+
|---|---|---|---|---|---|
|
|
11
|
+
| {EventName} | {Aggregate / Application Service} | {觸發條件} | `{Payload shape}` | {consumer names} | {in-process / outbox / integration event / manual} |
|
|
12
|
+
|
|
13
|
+
## Event Flow Notes
|
|
14
|
+
|
|
15
|
+
- {事件發生時序、交易邊界、重試或一致性注意事項}
|
|
16
|
+
|
|
17
|
+
## Open Questions
|
|
18
|
+
|
|
19
|
+
- {尚未確定的事件命名、payload 或 delivery expectation}
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
<!-- Template maintained by Dflow. See proposals/PROPOSAL-013 for origin. -->
|
|
2
|
+
|
|
3
|
+
# Glossary
|
|
4
|
+
|
|
5
|
+
> Ubiquitous Language for this project or bounded context.
|
|
6
|
+
|
|
7
|
+
## Terms
|
|
8
|
+
|
|
9
|
+
| Term | Definition | Bounded Context | Code Mapping | Notes |
|
|
10
|
+
|---|---|---|---|---|
|
|
11
|
+
| {Term} | {這個術語在業務中的定義} | {Context name} | `{Namespace/Class/Member}` | {optional notes} |
|
|
12
|
+
|
|
13
|
+
## Open Questions
|
|
14
|
+
|
|
15
|
+
- {需要和 domain expert 確認的術語或命名差異}
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: BUG-{NUMBER}
|
|
3
|
+
title: {簡述問題}
|
|
4
|
+
status: in-progress
|
|
5
|
+
bounded-context: {ContextName}
|
|
6
|
+
created: {YYYY-MM-DD}
|
|
7
|
+
branch: bugfix/BUG-{NUMBER}-{short-description}
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
<!--
|
|
11
|
+
Template note (for AI):
|
|
12
|
+
This is the **lightweight-spec** template — it corresponds to T2 Light
|
|
13
|
+
ceremony in the three-tier Ceremony Scaling (T1 Heavy / T2 Light /
|
|
14
|
+
T3 Trivial; see SKILL.md § Ceremony Scaling for the tier criteria).
|
|
15
|
+
|
|
16
|
+
- T1 Heavy → use templates/phase-spec.md instead
|
|
17
|
+
- T2 Light → THIS template; produces an independent file
|
|
18
|
+
- T3 Trivial → no independent file; just one inline row in _index.md
|
|
19
|
+
Lightweight Changes with a tag like [cosmetic] / [text] / [format]
|
|
20
|
+
|
|
21
|
+
Instance file location and naming:
|
|
22
|
+
Place the instantiated file inside the corresponding feature directory:
|
|
23
|
+
dflow/specs/features/active/{SPEC-ID}-{slug}/lightweight-{YYYY-MM-DD}-{slug}.md
|
|
24
|
+
or, when the lightweight change is a tracked bug:
|
|
25
|
+
dflow/specs/features/active/{SPEC-ID}-{slug}/BUG-{NUMBER}-{slug}.md
|
|
26
|
+
|
|
27
|
+
If the change is a standalone bug not yet attached to any existing
|
|
28
|
+
feature, /dflow:bug-fix must first create a feature directory (with a
|
|
29
|
+
minimal _index.md) before placing the lightweight-spec instance inside.
|
|
30
|
+
This keeps the structure invariant: every spec file lives under some
|
|
31
|
+
feature directory.
|
|
32
|
+
|
|
33
|
+
After finalizing this lightweight-spec, AI must:
|
|
34
|
+
1. Add an outbound-link row to the feature's _index.md Lightweight Changes table
|
|
35
|
+
(Tier = T2; description includes the link to this file)
|
|
36
|
+
2. Refresh the feature's _index.md Current BR Snapshot table to reflect
|
|
37
|
+
any BR ADDED / MODIFIED / REMOVED / RENAMED in this lightweight-spec
|
|
38
|
+
-->
|
|
39
|
+
|
|
40
|
+
# {問題簡述}
|
|
41
|
+
|
|
42
|
+
## Problem
|
|
43
|
+
|
|
44
|
+
{什麼東西壞了?或什麼行為不正確?}
|
|
45
|
+
|
|
46
|
+
## Behavior Delta
|
|
47
|
+
|
|
48
|
+
> 精簡 delta 格式:bug fix 多數只需 MODIFIED;若確實是新增規則可改用 ADDED、移除用 REMOVED、改名用 RENAMED。多項變更時照類別列。
|
|
49
|
+
|
|
50
|
+
### MODIFIED - behavior modified in this fix
|
|
51
|
+
#### Rule: BR-NN {規則名稱}
|
|
52
|
+
**Before**: Given {current Aggregate state} When {action} Then {current (incorrect) result} / {event}
|
|
53
|
+
**After**: Given {same state} When {same action} Then {correct result} / {event}
|
|
54
|
+
**Reason**: {why this change — bug / invariant violation / requirement clarification}
|
|
55
|
+
|
|
56
|
+
<!-- 若需要 ADDED / REMOVED / RENAMED / UNCHANGED 請比照 references/modify-existing-flow.md 的 Delta 格式 -->
|
|
57
|
+
|
|
58
|
+
|
|
59
|
+
## Root Cause
|
|
60
|
+
|
|
61
|
+
{為什麼會這樣?是邏輯錯誤?資料問題?還是需求理解有誤?}
|
|
62
|
+
|
|
63
|
+
## Fix Approach
|
|
64
|
+
|
|
65
|
+
{怎麼修?有沒有抽到 Domain 層的機會?}
|
|
66
|
+
|
|
67
|
+
<!-- dflow:section implementation-tasks -->
|
|
68
|
+
## Implementation Tasks
|
|
69
|
+
|
|
70
|
+
> Keep T2 Light tasks concise. If the fix scope starts to expand, AI should pause and ask the developer whether to keep this as T2 or upgrade it to T1. Do not auto-upgrade based on task count alone.
|
|
71
|
+
>
|
|
72
|
+
> Recommended layer tags (Core): `DOMAIN` / `APP` / `INFRA` / `API` / `TEST` / `DOC`
|
|
73
|
+
|
|
74
|
+
- [ ] {LAYER}-1: {minimal required change}
|
|
75
|
+
- [ ] TEST-1: {minimal verification / regression test}
|
|
76
|
+
- [ ] DOC-1: Update `_index.md` Lightweight Changes and Current BR Snapshot
|
|
77
|
+
|
|
78
|
+
Layer tag list above is the recommended set; the developer may extend with project-specific tags as needed.
|
|
79
|
+
|
|
80
|
+
## Tech Debt Discovered (if any)
|
|
81
|
+
|
|
82
|
+
{在修這個 bug 時發現的其他問題,記錄到 tech-debt.md}
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
<!-- Template maintained by Dflow. See proposals/PROPOSAL-013 for origin. -->
|
|
2
|
+
|
|
3
|
+
# Domain Models
|
|
4
|
+
|
|
5
|
+
> DDD model catalog for one bounded context.
|
|
6
|
+
|
|
7
|
+
## Context
|
|
8
|
+
|
|
9
|
+
- **Bounded Context**: {Context name}
|
|
10
|
+
- **Source Code Area**: `{project/path/or/namespace}`
|
|
11
|
+
- **Last Updated**: {YYYY-MM-DD}
|
|
12
|
+
|
|
13
|
+
## Aggregates
|
|
14
|
+
|
|
15
|
+
| Aggregate | Root Entity | Invariants | Code Mapping | Notes |
|
|
16
|
+
|---|---|---|---|---|
|
|
17
|
+
| {AggregateName} | {RootEntityName} | {核心不變量} | `{Namespace.Class}` | {optional notes} |
|
|
18
|
+
|
|
19
|
+
## Entities
|
|
20
|
+
|
|
21
|
+
| Entity | Responsibility | Key Identity | Aggregate | Code Mapping |
|
|
22
|
+
|---|---|---|---|---|
|
|
23
|
+
| {EntityName} | {核心職責} | {Id / composite key} | {AggregateName} | `{Namespace.Class}` |
|
|
24
|
+
|
|
25
|
+
## Value Objects
|
|
26
|
+
|
|
27
|
+
| Value Object | Responsibility | Equality Components | Code Mapping | Notes |
|
|
28
|
+
|---|---|---|---|---|
|
|
29
|
+
| {ValueObjectName} | {代表的概念} | {fields} | `{Namespace.Class}` | {optional notes} |
|
|
30
|
+
|
|
31
|
+
## Domain Services
|
|
32
|
+
|
|
33
|
+
| Service | Responsibility | Inputs / Outputs | Code Mapping | Notes |
|
|
34
|
+
|---|---|---|---|---|
|
|
35
|
+
| {ServiceName} | {跨 aggregate/entity/value object 的 domain operation} | {inputs -> outputs} | `{Namespace.Class}` | {optional notes} |
|
|
36
|
+
|
|
37
|
+
## Specifications
|
|
38
|
+
|
|
39
|
+
| Specification | Rule / Invariant | Used By | Code Mapping | Notes |
|
|
40
|
+
|---|---|---|---|---|
|
|
41
|
+
| {SpecificationName} | {規則或查詢條件} | {use case / aggregate} | `{Namespace.Class}` | {optional notes} |
|
|
42
|
+
|
|
43
|
+
## Repository Interfaces
|
|
44
|
+
|
|
45
|
+
| Repository | Aggregate | Query Responsibility | Code Mapping | Notes |
|
|
46
|
+
|---|---|---|---|---|
|
|
47
|
+
| {RepositoryName} | {AggregateName} | {查詢或保存責任} | `{Namespace.Interface}` | {optional notes} |
|
|
@@ -0,0 +1,195 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: {CONTEXT}-{NUMBER}
|
|
3
|
+
title: 功能標題
|
|
4
|
+
status: draft | in-progress | completed
|
|
5
|
+
bounded-context: {ContextName}
|
|
6
|
+
created: {YYYY-MM-DD}
|
|
7
|
+
author: {developer-name}
|
|
8
|
+
branch: feature/{CONTEXT}-{NUMBER}-{short-description}
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# {功能標題}
|
|
12
|
+
|
|
13
|
+
<!--
|
|
14
|
+
Template note (for AI):
|
|
15
|
+
This is the **phase-spec** template - one phase-spec captures one full
|
|
16
|
+
"Kickoff -> Domain -> Design -> Build -> Verify" cycle inside a feature directory.
|
|
17
|
+
A feature can have 1..N phase-specs; the feature-level dashboard lives in
|
|
18
|
+
the sibling `_index.md` (see templates/_index.md). The instance file name is
|
|
19
|
+
`phase-spec-YYYY-MM-DD-{slug}.md` placed at
|
|
20
|
+
`dflow/specs/features/active/{SPEC-ID}-{slug}/`.
|
|
21
|
+
|
|
22
|
+
Each section below carries an HTML comment indicating its fill-in phase (Phase 1-4).
|
|
23
|
+
These phase markers let /dflow:status and the completion checklist track progress.
|
|
24
|
+
Phases correspond to SKILL.md § Guiding Questions by Phase:
|
|
25
|
+
Phase 1 - Understanding (What & Why)
|
|
26
|
+
Phase 2 - Domain Modeling (BC, Aggregate, VO, Events)
|
|
27
|
+
Phase 3 - Spec Writing (Behavior + Rules + Edge Cases)
|
|
28
|
+
Phase 4 - Implementation Planning (layer-by-layer)
|
|
29
|
+
The "Implementation Tasks" section at the end is generated by AI after Phase 4 planning is done
|
|
30
|
+
(see new-feature-flow.md Step 5 end / new-phase-flow.md Step 4 end /
|
|
31
|
+
modify-existing-flow.md Step 3 end).
|
|
32
|
+
|
|
33
|
+
For phase 2+ specs in the same feature: only list BRs that are NEW or
|
|
34
|
+
MODIFIED in this phase under "Business Rules"; do not re-copy unchanged BRs from
|
|
35
|
+
prior phases. The cumulative state lives in the feature's `_index.md`
|
|
36
|
+
Current BR Snapshot table; the system-level current state lives in the
|
|
37
|
+
bounded context's `rules.md` / `behavior.md` (synced at /dflow:finish-feature).
|
|
38
|
+
-->
|
|
39
|
+
|
|
40
|
+
## Problem Description <!-- Fill timing: Phase 1 -->
|
|
41
|
+
|
|
42
|
+
> 用使用者的角度描述,避免技術用語。
|
|
43
|
+
|
|
44
|
+
## Domain Concepts <!-- Fill timing: Phase 2 -->
|
|
45
|
+
|
|
46
|
+
涉及的 Domain 概念(引用 `dflow/specs/domain/{context}/models.md`):
|
|
47
|
+
|
|
48
|
+
| Concept | Type | Description |
|
|
49
|
+
|---|---|---|
|
|
50
|
+
| {Name} | Aggregate Root / Entity / Value Object / Domain Service | 角色 |
|
|
51
|
+
|
|
52
|
+
更新檢查:
|
|
53
|
+
- [ ] `dflow/specs/domain/glossary.md` — 新術語
|
|
54
|
+
- [ ] `dflow/specs/domain/{context}/models.md` — 模型定義
|
|
55
|
+
- [ ] `dflow/specs/domain/{context}/events.md` — Domain Events
|
|
56
|
+
|
|
57
|
+
<!-- dflow:section behavior-scenarios -->
|
|
58
|
+
## Behavior Scenarios <!-- Fill timing: Phase 3 -->
|
|
59
|
+
|
|
60
|
+
### Main Success Scenario
|
|
61
|
+
|
|
62
|
+
```gherkin
|
|
63
|
+
Scenario: {情境名稱}
|
|
64
|
+
Given {Aggregate 的初始狀態}
|
|
65
|
+
When {呼叫的 Aggregate 方法或 Command}
|
|
66
|
+
Then {Aggregate 的新狀態}
|
|
67
|
+
And {產生的 Domain Event}
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### Alternative Scenarios
|
|
71
|
+
|
|
72
|
+
```gherkin
|
|
73
|
+
Scenario: {替代情境}
|
|
74
|
+
Given {不同初始狀態}
|
|
75
|
+
When {相同或不同操作}
|
|
76
|
+
Then {不同結果}
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
## Business Rules <!-- Fill timing: Phase 3 -->
|
|
80
|
+
|
|
81
|
+
> Phase 2+ 注意:本段僅列**本 phase 新增 / 修改到的 BR**;未變動的 BR 不重抄
|
|
82
|
+
> (它們的當前狀態見 feature 的 `_index.md` Current BR Snapshot 表)。
|
|
83
|
+
|
|
84
|
+
| BR-ID | Rule | Implementation Location |
|
|
85
|
+
|---|---|---|
|
|
86
|
+
| BR-01 | {規則描述} | Domain: {Entity/VO/Service} |
|
|
87
|
+
| BR-02 | {規則描述} | Domain: {Entity/VO/Service} |
|
|
88
|
+
|
|
89
|
+
## Delta from prior phases <!-- Fill timing: Phase 3; skip for the first phase -->
|
|
90
|
+
|
|
91
|
+
> 本段僅記**本 phase 相對前一 phase 的變化**,不累積歷史。歷史由 feature 目錄下
|
|
92
|
+
> 各 phase-spec 的本段串接閱讀;feature 層的當前累積狀態見 `_index.md` 的
|
|
93
|
+
> Current BR Snapshot;BC 層當前狀態見 `dflow/specs/domain/{context}/rules.md` /
|
|
94
|
+
> `behavior.md`(在 `/dflow:finish-feature` 時同步)。
|
|
95
|
+
>
|
|
96
|
+
> **首 phase**:標註「首 phase,無前置 Delta」即可,不需逐項填。
|
|
97
|
+
> **Phase 2+**:必填;格式沿用 modify-existing-flow.md 的 Delta 規則
|
|
98
|
+
> (ADDED / MODIFIED / REMOVED / RENAMED + 選用 UNCHANGED)。
|
|
99
|
+
|
|
100
|
+
### ADDED - BR / behavior added in this phase
|
|
101
|
+
#### Rule: BR-NN {規則名稱}
|
|
102
|
+
Given {Aggregate 初始狀態}
|
|
103
|
+
When {呼叫的 Command 或 Aggregate 方法}
|
|
104
|
+
Then {新的 Aggregate 狀態}
|
|
105
|
+
And {產生的 Domain Event}
|
|
106
|
+
|
|
107
|
+
### MODIFIED - BR / behavior modified in this phase
|
|
108
|
+
#### Rule: BR-NN {規則名稱}
|
|
109
|
+
**Before**: Given … When … Then {old result} / {old event}
|
|
110
|
+
**After**: Given … When … Then {new result} / {new event}
|
|
111
|
+
**Reason**: {why this change}
|
|
112
|
+
|
|
113
|
+
### REMOVED - BR removed in this phase
|
|
114
|
+
#### Rule: BR-NN {規則名稱}
|
|
115
|
+
**Reason**: {why removed}
|
|
116
|
+
|
|
117
|
+
### RENAMED - BR renamed in this phase
|
|
118
|
+
#### Rule: {old name} -> {new name}
|
|
119
|
+
**Reason**: {why renamed}
|
|
120
|
+
|
|
121
|
+
### UNCHANGED - explicitly unaffected (optional)
|
|
122
|
+
- BR-003 金額上限
|
|
123
|
+
- BR-005 提交後不可修改
|
|
124
|
+
|
|
125
|
+
## Edge Cases <!-- Fill timing: Phase 3 -->
|
|
126
|
+
|
|
127
|
+
| ID | Case | Expected Handling |
|
|
128
|
+
|---|---|---|
|
|
129
|
+
| EC-01 | {邊界描述} | {處理方式} |
|
|
130
|
+
|
|
131
|
+
## Domain Events <!-- Fill timing: Phase 2-3; draft during design, finalized during spec writing -->
|
|
132
|
+
|
|
133
|
+
| Event | Trigger | Handler | Sync / Async |
|
|
134
|
+
|---|---|---|---|
|
|
135
|
+
| {EventName} | {何時觸發} | {Handler} | 同步/異步 |
|
|
136
|
+
|
|
137
|
+
## Implementation Plan (Layer by Layer) <!-- Fill timing: Phase 4 -->
|
|
138
|
+
|
|
139
|
+
### Domain Layer
|
|
140
|
+
> Aggregate 設計、Value Objects、Events、Interfaces
|
|
141
|
+
|
|
142
|
+
### Application Layer
|
|
143
|
+
> Command/Query、Handler、Validator、DTO
|
|
144
|
+
|
|
145
|
+
### Infrastructure Layer
|
|
146
|
+
> EF 設定、Repository 實作、外部服務
|
|
147
|
+
|
|
148
|
+
### Presentation Layer
|
|
149
|
+
> API Endpoint 設計、Request/Response 模型
|
|
150
|
+
|
|
151
|
+
## Data Structure Changes <!-- Fill timing: Phase 4 -->
|
|
152
|
+
|
|
153
|
+
| Table | Column | Change Type | Description |
|
|
154
|
+
|---|---|---|---|
|
|
155
|
+
| {Table} | {Column} | 新增/修改/刪除 | |
|
|
156
|
+
|
|
157
|
+
## Test Strategy <!-- Fill timing: Phase 4 -->
|
|
158
|
+
|
|
159
|
+
### Domain Unit Tests
|
|
160
|
+
- [ ] {不變條件測試}
|
|
161
|
+
- [ ] {業務規則測試}
|
|
162
|
+
- [ ] {Value Object 相等性測試}
|
|
163
|
+
|
|
164
|
+
### Application Tests
|
|
165
|
+
- [ ] {Command Handler 測試}
|
|
166
|
+
- [ ] {Query Handler 測試}
|
|
167
|
+
|
|
168
|
+
### Integration Tests
|
|
169
|
+
- [ ] {Repository 測試}
|
|
170
|
+
|
|
171
|
+
<!-- dflow:section open-questions -->
|
|
172
|
+
## Open Questions <!-- Fill timing: Phase 1-4 -->
|
|
173
|
+
|
|
174
|
+
- {尚未釐清的需求、規則、資料或實作問題}
|
|
175
|
+
|
|
176
|
+
<!-- dflow:section implementation-tasks -->
|
|
177
|
+
## Implementation Tasks <!-- Fill timing: generated by AI after Phase 4; all items should be checked at completion -->
|
|
178
|
+
|
|
179
|
+
> AI 在 Phase 4 實作規劃完成後,根據「Implementation Plan (Layer by Layer)」產生的具體任務清單。
|
|
180
|
+
> 格式:`[LAYER]-[NUMBER]: 任務描述`
|
|
181
|
+
> 分類標籤(Core 版,對應 Clean Architecture 各層):
|
|
182
|
+
> - `DOMAIN` — Aggregate、Entity、VO、Domain Event、Domain Service、Repository Interface
|
|
183
|
+
> - `APP` — Command/Query、Handler、Validator、DTO、Event Handler
|
|
184
|
+
> - `INFRA` — EF Configuration、Repository Impl、外部服務 adapter、Migration
|
|
185
|
+
> - `API` — Controller / Minimal API、Request/Response 模型、Swagger
|
|
186
|
+
> - `TEST` — 各層測試案例
|
|
187
|
+
> 建議產出順序與實作順序相符:DOMAIN -> APP -> INFRA -> API。
|
|
188
|
+
> 本段在 spec 歸檔(搬到 `completed/`)前應確認全部勾選,或明確標註未完成項的 follow-up。
|
|
189
|
+
|
|
190
|
+
- [ ] DOMAIN-1: {任務描述}
|
|
191
|
+
- [ ] DOMAIN-2: {任務描述}
|
|
192
|
+
- [ ] APP-1: {任務描述}
|
|
193
|
+
- [ ] INFRA-1: {任務描述}
|
|
194
|
+
- [ ] API-1: {任務描述}
|
|
195
|
+
- [ ] TEST-1: {任務描述}
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
<!-- Template maintained by Dflow. See proposals/PROPOSAL-013 for origin. -->
|
|
2
|
+
|
|
3
|
+
# Business Rules
|
|
4
|
+
|
|
5
|
+
> Declarative BR-ID index for one bounded context.
|
|
6
|
+
|
|
7
|
+
<!-- dflow:section business-rules -->
|
|
8
|
+
## Rule Index
|
|
9
|
+
|
|
10
|
+
| BR-ID | Rule summary | Behavior anchor | Aggregate | Status | Last updated |
|
|
11
|
+
|---|---|---|---|---|---|
|
|
12
|
+
| BR-001 | {業務規則摘要} | [BR-001](./behavior.md#br-001-rule-name) | {AggregateName} | draft | {YYYY-MM-DD} |
|
|
13
|
+
|
|
14
|
+
## Status Legend
|
|
15
|
+
|
|
16
|
+
| Status | Meaning |
|
|
17
|
+
|---|---|
|
|
18
|
+
| draft | Rule is identified but not fully validated. |
|
|
19
|
+
| active | Rule is validated and expected to be enforced. |
|
|
20
|
+
| deprecated | Rule is retained for history but no longer active. |
|
|
21
|
+
|
|
22
|
+
## Open Questions
|
|
23
|
+
|
|
24
|
+
- {需要 domain expert 確認的規則}
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
<!-- Template maintained by Dflow. See proposals/PROPOSAL-013 for origin. -->
|
|
2
|
+
|
|
3
|
+
# Architecture Tech Debt
|
|
4
|
+
|
|
5
|
+
> Architecture debt backlog discovered during SDD/DDD work.
|
|
6
|
+
|
|
7
|
+
## Debt Items
|
|
8
|
+
|
|
9
|
+
| Item | Layer | Decision / debt | Impact | Follow-up | Status |
|
|
10
|
+
|---|---|---|---|---|---|
|
|
11
|
+
| {Debt item} | {Domain/Application/Infrastructure/API} | {決策或債務描述} | {影響範圍} | {後續處理方式} | {open/planned/in-progress/done} |
|
|
12
|
+
|
|
13
|
+
## Follow-up Notes
|
|
14
|
+
|
|
15
|
+
- {需要後續 proposal、ADR、refactor 或 architecture review 的事項}
|
|
@@ -0,0 +1,167 @@
|
|
|
1
|
+
<!-- Scaffolding template maintained alongside Dflow skill. See proposals/PROPOSAL-010 for origin. -->
|
|
2
|
+
|
|
3
|
+
# CLAUDE.md Snippet — Dflow Adoption
|
|
4
|
+
|
|
5
|
+
> This file is a **snippet**, not a standalone `CLAUDE.md`. Its purpose
|
|
6
|
+
> is to be merged into your project's root `CLAUDE.md`:
|
|
7
|
+
>
|
|
8
|
+
> - If your project does **not** yet have a `CLAUDE.md`, the
|
|
9
|
+
> `npx dflow-sdd-ddd init` flow will create one using this snippet as
|
|
10
|
+
> the starting content.
|
|
11
|
+
> - If your project **already has** a `CLAUDE.md`, the init flow will
|
|
12
|
+
> copy this file into your repo and prompt you to merge the
|
|
13
|
+
> sections below into the appropriate places in your existing
|
|
14
|
+
> `CLAUDE.md`. No auto-merge — you keep editorial control.
|
|
15
|
+
|
|
16
|
+
The snippet follows the Dflow `templates/CLAUDE.md` H2 segmentation
|
|
17
|
+
(established in PROPOSAL-007c): **System Context** (what the system is)
|
|
18
|
+
and **Development Workflow** (how we work). Keep those two H2 sections as the backbone
|
|
19
|
+
when merging into an existing `CLAUDE.md`.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Snippet to merge into `CLAUDE.md`
|
|
24
|
+
|
|
25
|
+
```markdown
|
|
26
|
+
# Project: {系統名稱} — ASP.NET WebForms
|
|
27
|
+
|
|
28
|
+
**重要:所有開發工作都必須遵循本文件定義的流程。**
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## System Context
|
|
33
|
+
|
|
34
|
+
> 技術棧、業務領域、目錄結構
|
|
35
|
+
|
|
36
|
+
### Background
|
|
37
|
+
|
|
38
|
+
這是一個運行中的 ASP.NET WebForms 系統,{一句話描述業務領域:例如
|
|
39
|
+
「提供員工費用報銷」/「處理 HR 人事流程」/「訂單管理」}。採用 Dflow
|
|
40
|
+
(SDD/DDD workflow guardian skill)引導開發流程,同時為未來遷移到
|
|
41
|
+
ASP.NET Core 做準備。
|
|
42
|
+
|
|
43
|
+
{選填:補上團隊規模、使用者規模、主要 stakeholders 等 context,
|
|
44
|
+
1-3 行即可。完整內容放在 `dflow/specs/shared/_overview.md`。}
|
|
45
|
+
|
|
46
|
+
### Project Structure
|
|
47
|
+
|
|
48
|
+
```
|
|
49
|
+
dflow/specs/
|
|
50
|
+
├── shared/ # 專案級治理文件(由 npx dflow-sdd-ddd init 寫入)
|
|
51
|
+
│ ├── _overview.md # 系統現況與遷移策略
|
|
52
|
+
│ ├── _conventions.md # 規格撰寫慣例
|
|
53
|
+
│ └── Git-principles-*.md # Git 規範(gitflow 或 trunk 版)
|
|
54
|
+
├── domain/ # 領域知識
|
|
55
|
+
│ ├── glossary.md # 術語表(Ubiquitous Language)
|
|
56
|
+
│ └── {context}/ # 按 Bounded Context 分
|
|
57
|
+
│ ├── context.md
|
|
58
|
+
│ ├── models.md
|
|
59
|
+
│ ├── rules.md
|
|
60
|
+
│ └── behavior.md
|
|
61
|
+
├── features/
|
|
62
|
+
│ ├── active/
|
|
63
|
+
│ │ └── {SPEC-ID}-{slug}/
|
|
64
|
+
│ │ ├── _index.md
|
|
65
|
+
│ │ ├── phase-spec-YYYY-MM-DD-{slug}.md
|
|
66
|
+
│ │ └── lightweight-YYYY-MM-DD-{slug}.md
|
|
67
|
+
│ ├── completed/
|
|
68
|
+
│ └── backlog/
|
|
69
|
+
└── migration/
|
|
70
|
+
└── tech-debt.md
|
|
71
|
+
|
|
72
|
+
src/
|
|
73
|
+
├── Domain/ # 抽離的領域邏輯(純 C#)
|
|
74
|
+
│ ├── {BoundedContext}/
|
|
75
|
+
│ └── SharedKernel/
|
|
76
|
+
└── Pages/ # 既有 WebForms 頁面
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
## Development Workflow
|
|
82
|
+
|
|
83
|
+
> SDD 流程、Git 整合、Domain 層規範、術語表、AI 協作
|
|
84
|
+
|
|
85
|
+
### Core Principles
|
|
86
|
+
|
|
87
|
+
1. **Spec Before Code** — 沒有規格就不寫實作(依 Ceremony Scaling 調整嚴謹度)
|
|
88
|
+
2. **Domain Extraction** — 業務邏輯屬於 `src/Domain/`,不屬於 Code-Behind
|
|
89
|
+
3. **Ubiquitous Language** — 使用 `dflow/specs/domain/glossary.md` 中定義的術語
|
|
90
|
+
4. **Migration Awareness** — 每個決策都要考慮未來 ASP.NET Core 遷移
|
|
91
|
+
|
|
92
|
+
### Dflow Skill — Canonical Decision Logic Lives in the Skill
|
|
93
|
+
|
|
94
|
+
AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
|
|
95
|
+
(T1/T2/T3)、各 `/dflow:` 命令的具體流程,**全部定義於 Dflow skill
|
|
96
|
+
本體**(`sdd-ddd-webforms-skill/SKILL.md` 與 `references/*.md`)。
|
|
97
|
+
本 `CLAUDE.md` 不重述這些內容,避免雙份維護。
|
|
98
|
+
|
|
99
|
+
當你作為 AI assistant 被呼叫時,若偵測到使用者需要 SDD/DDD 工作流
|
|
100
|
+
引導,請參考 Dflow entry points:
|
|
101
|
+
|
|
102
|
+
- `npx dflow-sdd-ddd init` — 專案初始化(建立 `dflow/specs/` 結構)
|
|
103
|
+
- `/dflow:new-feature` — 新功能開發
|
|
104
|
+
- `/dflow:new-phase` — 在 active feature 內新增階段
|
|
105
|
+
- `/dflow:modify-existing` — 修改既有功能
|
|
106
|
+
- `/dflow:bug-fix` — 輕量修復
|
|
107
|
+
- `/dflow:finish-feature` — feature 收尾
|
|
108
|
+
- `/dflow:pr-review` — PR 審查
|
|
109
|
+
- `/dflow:verify` — rules.md ↔ behavior.md 漂移檢查
|
|
110
|
+
- `/dflow:status` / `/dflow:next` / `/dflow:cancel` — 狀態管理
|
|
111
|
+
|
|
112
|
+
### Project-Level Supplemental Rules
|
|
113
|
+
|
|
114
|
+
(本 `CLAUDE.md` 只記這一層——Dflow skill 不管的專案決策)
|
|
115
|
+
|
|
116
|
+
- **Git 分支策略**:見 `dflow/specs/shared/Git-principles-{gitflow|trunk}.md`
|
|
117
|
+
- **規格撰寫慣例**:見 `dflow/specs/shared/_conventions.md`
|
|
118
|
+
- **系統現況與遷移**:見 `dflow/specs/shared/_overview.md`
|
|
119
|
+
- {其他專案特有規則,例如「JPY 金額必須以最小貨幣單位(yen)儲存」/
|
|
120
|
+
「所有費用報銷需主管審核」/「跨時區行程以 UTC 記錄」}
|
|
121
|
+
|
|
122
|
+
### Domain Layer Rules (`src/Domain/`)
|
|
123
|
+
|
|
124
|
+
此目錄中的程式碼必須遵守(與 Dflow skill 的 Domain Layer Rules 一致):
|
|
125
|
+
|
|
126
|
+
- ❌ 不可引用 `System.Web` 或任何 WebForms 命名空間
|
|
127
|
+
- ❌ 不可直接存取資料庫(使用 interface + Repository pattern)
|
|
128
|
+
- ❌ 不可使用 `HttpContext`、`Session`、`ViewState`
|
|
129
|
+
- ❌ 不可有 UI 相關邏輯
|
|
130
|
+
- ✅ 純 C# 類別,可直接搬到 ASP.NET Core 專案
|
|
131
|
+
- ✅ 所有公開行為都能在沒有 Web 基礎設施的情況下測試
|
|
132
|
+
|
|
133
|
+
### AI Collaboration Notes
|
|
134
|
+
|
|
135
|
+
- 遇到開發需求時,優先引導使用 `/dflow:` 命令
|
|
136
|
+
- 回答 Domain 相關問題時,優先參考 `dflow/specs/domain/` 中的文件
|
|
137
|
+
- 發現 Code-Behind 中的業務邏輯時,建議抽離到 `src/Domain/`
|
|
138
|
+
- 建立分支前,確認命名符合規範且對應 spec 存在
|
|
139
|
+
- 詳細 Git 操作規則見 `dflow/specs/shared/Git-principles-{gitflow|trunk}.md`
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
---
|
|
143
|
+
|
|
144
|
+
## Merge Guidance
|
|
145
|
+
|
|
146
|
+
When merging this snippet into an existing `CLAUDE.md`:
|
|
147
|
+
|
|
148
|
+
1. **Keep the two H2 sections** (`System Context` / `Development Workflow`) as the
|
|
149
|
+
backbone. This alignment with the Dflow skill's
|
|
150
|
+
`templates/CLAUDE.md` is important — AI assistants navigate by
|
|
151
|
+
these headings.
|
|
152
|
+
2. **Under `System Context`**: merge the background paragraph and the
|
|
153
|
+
directory tree. If your project already documents directory
|
|
154
|
+
structure elsewhere, keep the tree pointing to `dflow/specs/` and
|
|
155
|
+
`src/Domain/` at minimum (those are Dflow-specific).
|
|
156
|
+
3. **Under `Development Workflow`**: merge the core principles, the Dflow skill
|
|
157
|
+
pointer, and the project-level supplementary rules. The Domain
|
|
158
|
+
layer rules and AI collaboration rules can be kept here or
|
|
159
|
+
cross-referenced from the scaffolding `Git-principles-*.md`.
|
|
160
|
+
4. **Avoid duplication**: do not re-inline the Dflow skill's decision
|
|
161
|
+
tree, Workflow Transparency rules, or Ceremony Scaling criteria
|
|
162
|
+
into `CLAUDE.md`. Let `CLAUDE.md` point to the skill, not
|
|
163
|
+
duplicate it.
|
|
164
|
+
|
|
165
|
+
If you are starting from scratch (no existing `CLAUDE.md`), the
|
|
166
|
+
`npx dflow-sdd-ddd init` flow will install this snippet as-is and you
|
|
167
|
+
can refine from there.
|