# DDD Taiwan — full article text

> Complete text of DDD Taiwan community articles. See https://ddd-tw.com/llms.txt for the curated index of pages, talks, events, and reading.

---

# Understand the Problem First — Chaining Impact Mapping, Event Storming, and Continuous Architecture into One Combo

- URL: https://ddd-tw.com/en/posts/2026-07-method-stack-en/
- Author: Kim Kao
- Published: 2026-07-21
- Language: en

A few years ago I met a retail client whose previous vendor had already handed them the answer: "Move everything to Kubernetes and your problems go away." The real problem was a twenty-year-old system underneath that nobody fully understood anymore. **They knew the answer before they understood the problem.**

I didn't argue about Kubernetes with anyone. Instead I did two things: I used **Impact Mapping** to ask the decision-makers and functional leads, "Who would support the goal of month-over-month revenue growth? Whose behavior needs to change?" Then I ran a **two-day Event Storming workshop with forty to fifty people**, laying the entire business flow out on the wall. The answer surfaced on its own: the place truly worth starting from was merchant management — nothing to do with Kubernetes.

This article isn't about which method is best. It's about **how each one does its own job**:

## Each method answers one question

**Cynefin — what kind of situation are we in?**
Clear problems take best practices; complicated ones need expert analysis; complex ones can only be probed, sensed, and responded to. Picking tools before reading the situation is where most project disasters begin. Modernizing a twenty-year-old system almost always lands in the complex domain — which means you need methods of exploration, not ready-made answers.

**Impact Mapping — why are we doing this, and who can help?**
Goal → actors → impacts → deliverables. Its greatest value is flipping "we need to build feature X" into "whose behavior must change for the goal to be met." The question in the story above came straight from here.

**Wardley Mapping — where are these components on the evolution axis?**
Draw the value chain against evolution and you can see what to build, what to buy, and what is commoditizing. Technology selection stops being a matter of faith and becomes a strategic conversation with actual terrain.

**Event Storming — what actually happens in this domain?**
Put everyone who knows a piece of the business in one room and lay out domain events on orange stickies. The output is more than a process diagram — it's shared language, proto-bounded-contexts, and the collective realization of "so *that's* how your department understands this."

**Domain Storytelling — does this concrete case really flow that way?**
Event Storming gives you the panorama; Domain Storytelling verifies the details one concrete story at a time. They complement each other.

**Specification by Example — are the rules actually clear?**
Turn requirement conversations into key examples (Example Mapping is its lightweight workshop form), and the examples become acceptance tests. Business rules stop hiding in someone's head.

**Rozanski & Woods Viewpoints & Perspectives — who is the architecture accountable to?**
Seven viewpoints and eight perspectives force you to face the fact that developers are not your only stakeholders. Security, performance, evolvability — each perspective is an interrogation of your architecture. This is the bedrock of continuous architecture: architecture is an ongoing socio-technical activity, not a one-time technical decision.

**DDD, strategic and tactical — the code comes last.**
Bounded contexts, context mapping, aggregates. Note the position: it sits at the end of the combo, because the quality of your model depends on the understanding every earlier step feeds into it.

## Not a pipeline — a loop

In practice these methods never run as a straight line. Questions unearthed in Event Storming send you back to Impact Mapping to refocus; an architectural perspective review forces another modeling workshop. **The handoffs and the doubling-back between methods are where the real craft lives.**

Over the past year I've brought this combo into large AI-driven modernization work: AI agents working along the same methodology — global analysis first, then architecture mapping, then domain modeling, each phase's output feeding the next. The methods didn't become obsolete because of AI; they became the skeleton for orchestrating agents. **AI accelerates the execution, but understanding the problem first is still a human's job.**

## Want to practice?

Every method here has a real training ground in this community: the [annual conference](/en/events/) regularly runs Event Storming and Domain Storytelling workshops, the [knowledge base](/en/knowledge/) has an entry for every book mentioned above, and there are two 320+ star Event Storming workshop repos on [GitHub](https://github.com/ddd-tw) you can follow along with.

Understand the problem first. See you at the community.

---

# 先懂問題，再談解法 — 我如何把 Impact Mapping、Event Storming 與持續演進架構串成一套組合拳

- URL: https://ddd-tw.com/posts/2026-07-method-stack/
- Author: Kim Kao
- Published: 2026-07-21
- Language: zh-TW

幾年前我遇到一個零售業的客戶，前一家廠商已經給了他們答案：「全部搬上 Kubernetes，問題就解決了。」但真正的問題，是底層那套二十年、沒有人完整搞得懂的老系統。**他們在理解問題之前，就已經知道答案了。**

我沒有跟任何人爭論 Kubernetes 的優劣。我反過來做了兩件事：先用 **Impact Mapping** 對決策者與各功能主管提問 —「誰會支持營收月月成長這個目標？他們的行為需要發生什麼改變？」再辦一場**兩天、四五十人的 Event Storming**，把整條業務流攤在牆上。答案自己浮現了：真正該切入的地方是商家管理（merchant management），跟 Kubernetes 一點關係也沒有。

這篇文章想講的不是哪個方法最好，而是**它們如何各司其職**。這套組合拳裡的每一個方法，回答的是不同層次的問題：

## 每個方法回答一個問題

**Cynefin — 我們現在身處什麼情境？**
清晰的問題套最佳實踐就好；繁雜的問題請專家分析；複雜的問題只能先探測、再感知、再回應。分不清情境就選工具，是多數專案災難的起點。二十年老系統的現代化，幾乎永遠落在「複雜」象限 — 這代表你需要的是探索的方法，不是現成的答案。

**Impact Mapping — 為什麼做？誰能幫我們達成？**
目標 → 角色 → 影響 → 交付物，四層提問。它最大的價值是把「我們要做 X 功能」翻轉成「誰的行為改變了，目標才會達成」。上面故事裡那個問題，就是從這裡來的。

**Wardley Mapping — 這些元件在演化的哪個階段？**
把價值鏈畫在演化軸上，你才知道哪些該自己建、哪些該用現成的、哪些正在商品化。它讓「技術選型」從信仰之爭變成有地形可循的策略討論。

**Event Storming — 領域裡實際發生了什麼事？**
把所有知道業務片段的人放進同一個房間，用橘色便利貼把領域事件攤開。它的產出不只是流程圖 — 是共同語言、是 Bounded Context 的雛形、是「原來你們部門是這樣理解這件事的」的集體頓悟。

**Domain Storytelling — 這個具體案例真的是這樣走的嗎？**
Event Storming 給你全景，Domain Storytelling 用一個個具體故事驗證細節。兩者互補。

**Specification by Example — 規則說清楚了嗎？**
把需求對話落成關鍵實例（Example Mapping 是它輕量的工作坊形式），實例直接變成驗收測試。業務規則從此不再躲在某個人的腦袋裡。

**Rozanski & Woods Viewpoints & Perspectives — 架構對誰負責？**
7 個視點、8 個視角，強迫你面對「利害關係人不只有開發者」這個事實。安全、效能、演進性 — 每個視角都是一次對架構的拷問。這是「持續演進架構」的基石：架構不是一次性的技術決策，而是持續演進的社會技術活動。

**DDD 戰略與戰術 — 最後才是程式碼。**
Bounded Context、Context Mapping、Aggregate。注意順序：它在組合拳的最後，因為建模的品質取決於前面每一步餵給它的理解。

## 它們不是流水線，是循環

實務上這些方法不會排成一條直線跑完。Event Storming 挖出的疑問會把你送回 Impact Mapping 重新對焦；架構視角的檢視會逼你重開一場建模工作坊。**方法之間的接力與回頭，才是真正的功夫。**

最近一年我把這套組合拳帶進了 AI 驅動的大型現代化專案：讓 AI agents 沿著同樣的方法論工作 — 先全域分析、再架構映射、最後領域建模，每個階段的產出都是下一個階段的輸入。方法論沒有因為 AI 而過時，反而成了 agent 編排的骨架：**AI 加速的是執行，但「先懂問題」這件事，仍然是人的責任。**

## 想動手練？

這些方法在社群都有實際的練習場：[年會](/events/)固定有 Event Storming 與 Domain Storytelling 工作坊，[知識庫](/knowledge/)裡有上面每一本書的入口，[GitHub](https://github.com/ddd-tw) 上有兩個 320+ 星的 Event Storming workshop repo 可以直接跟著做。

先懂問題，再談解法。我們在社群見。

---

# The New Website Is Live — How Content Publishing Works

- URL: https://ddd-tw.com/en/posts/2026-07-welcome-en/
- Author: DDD Taiwan
- Published: 2026-07-20
- Language: en

The new DDD Taiwan website is officially live. Here is the new content publishing workflow:

1. Add a Markdown file under `src/content/posts/` (fill in `title`, `description`, and `pubDate` in the frontmatter).
2. Open a Pull Request for community members to review.
3. Once merged to `main`, GitHub Actions automatically builds and deploys the site to ddd-tw.com.

For republished Papers articles, please also add `source` (a link to the original) and `authorization` (a record of the author's permission) to the frontmatter, so they can be verified during review.

---

# 新官網上線 — 內容發布流程說明

- URL: https://ddd-tw.com/posts/2026-07-welcome/
- Author: DDD Taiwan
- Published: 2026-07-20
- Language: zh-TW

DDD Taiwan 新官網正式上線。新的內容發布流程：

1. 在 `src/content/posts/` 新增一個 Markdown 檔（frontmatter 填 `title`、`description`、`pubDate`）。
2. 開 Pull Request，由社群成員 Review。
3. Merge 到 `main` 後，GitHub Actions 會自動建構並部署到 ddd-tw.com。

Papers 轉載類文章請在 frontmatter 補上 `source`（原文連結）與 `authorization`（作者授權紀錄），Review 時一併確認。