前言

前面已經介紹了一些理論，現在開始針對我們的主題——To-Do List 做一些分析。
先說好，實際進行 DDD 設計時並沒有這麼簡單，我會忽略許多設計元素，只講述我自己認為的重點。畢竟這裡的實戰只有我一個人，和一個簡單的 Domain。

戰略設計 (Strategic Design)

我想像中的 To-Do List 會有以下功能：

1. 使用者可以任意創建帳號。
2. 使用者需要能夠使用該帳號登入。
3. 帳號創建成功後，會自動生成一個 Default 的 To-Do List。
4. 每個使用者可以創建多個 To-Do Lists。
5. 每個 To-Do List 可以包含多個 To-Do Items。
6. 刪除 List 時，該 List 的 Items 也會一併刪除。
7. Items 可以標記為完成或被刪除。

To-Do List 是產品的核心功能，其他的帳號管理只是輔助工具。因此，我們可以簡單將功能拆分為兩個 Domain：

1. Todo Service —— 作為 Core Domain。
2. User Service —— 作為 Support/Generic Domain。

功能分析

為了分析這些功能，我們可以簡單地使用不同顏色的便利貼來代表不同的意義：

• Actor —— 操作者
• Aggregate —— 聚合物件
• Command —— 指令
• Event —— 事件
• Policy —— Domain 的規範
• System —— 關聯系統
• Read Model —— 輸出資料

大致上，我們可以這樣子使用。

接著，我們回到一開始描述的功能，並貼上相應的便利貼：

1. 使用者可以任意創建帳號
   
2. 使用者可以利用帳號登入
   
3. 帳號創建成功後會自動生成 Default 的 To-Do List
   
4. 使用者可以創建多個 To-Do Lists
   
5. 每個 To-Do List 可包含多個 To-Do Items
   
6. 刪除 List 後，其 Items 也會被刪除
   
7. Items 可以完成或刪除
   

Overall

總結

在這之後，我們把關鍵的 Command 和 Event 根據 Service 和 Aggregate 整理一下，去掉重複的物件，劃分相依性，最後寫上 Context Map。

這樣，一個邊界圖就完成了。看到成果後，我自己都覺得這麼直觀的東西，幹嘛要寫得這麼複雜呢？不過，現實問題通常不會這麼直觀，這裡主要是希望讀者能夠理解 DDD 的戰略設計 如何一步步釐清產品需求中的所有細節，並規劃出合理的架構設計。

後續

接下來的篇章，將會分析與實作 Tactical Design，目標是設計出 Aggregate Model 和 Data Model。結束後就可以開始實作啦！