這兩日在開發某個系統專案時，和 AI 持續討論軟體架構與設計決策，其中有一段關於 DDD Application Layer 的討論，我覺得特別有意思。
這也讓我更明確感受到：真正有價值的 AI 協作，不只是取得答案，而是在反覆討論、質疑、修正與形成共識的過程中，讓彼此的思考更清楚，甚至成為一種共同成長的方式。
我們先討論 Application Service 的「顆粒度（Granularity）」。
過去我的習慣比較偏向以 Use Case，也就是「使用者操作目的」來界定 Service 的顆粒度。
但到了 AI 時代，我開始重新思考這個界線。
原因是 AI Agent 能夠一次理解、處理與修改的程式範圍，比過去人工開發時更廣。原本為了讓開發者容易掌握，而切得較細的 Service Boundary，未必還需要維持同樣的顆粒度。
因此我開始傾向把 Application Service 的範圍放大，改以「業務功能模組」作為一個 Service，例如：
OrderService、PaymentService、InventoryService。
AI 接受這個方向，但建議把「功能模組」改成更精確的 Business Capability（業務能力）。
這個建議我很認同。
因為「功能模組」其實很容易受到 UI、系統切分方式或開發組織影響；Business Capability 則更接近「這個系統究竟具備什麼業務能力」，邊界會清楚很多。
於是我們形成了一個共識：
Application Service 可以用 Business Capability 作為主要邊界，而 Use Case 仍保留作為使用者操作目的與應用流程的設計單位。
接著又討論到另一個很典型的 DDD 問題：跨模組流程到底要怎麼處理？
AI 一開始採取比較典型、嚴謹的分層思維，希望 Application Layer 主要負責流程協調（Orchestration），商務規則則盡量交由 Domain 處理。
我的看法則比較務實。
如果是中小型的 單體應用架構（Monolithic）Application，沒有必要把內部模組設計成彼此高度隔離，甚至採 Microservices 那樣透過 API 才能合作。這樣雖然邊界漂亮，但設計、實作與交易控管的成本都會明顯提高。
所以我的主張是：
Application Service 可以負責控制邏輯，直接透過各 儲庫（Repository）存取所需資料，也可以先承擔簡單的 Business Logic。
例如某個跨業務能力的流程，需要同時處理訂單、付款與庫存資料時，所屬的 Application Service 可以直接協調對應的 Repository，不需要再透過多層 Service 彼此呼叫。
AI 接受這個設計，但提出一個補充：
按照較嚴謹的 DDD，Business Logic 最好還是放到 Domain Object。
我的看法則是：不需要太早把設計職責切分得過細。
如果只是簡單的條件判斷，而且只在單一流程使用，先寫在 Service 裡完全可以接受。
真正需要重構到 Domain 的時機，應該是：
邏輯開始變複雜、有多個條件或 invariant；
或同一段業務規則開始被多個 Service 共用；
或這段邏輯本身已經形成一個明確的 Domain Concept。
AI 最後也接受這個方向，而且反過來幫我補上了一套「什麼時候應該抽離 Domain Logic」的判斷規範。
我覺得這種務實、簡化的 DDD 架構，特別適合中小型系統。
它不像完整 DDD 那樣一開始就承擔較高的設計成本，但仍然保留清楚的分層、業務邊界與重構空間。
也就是說，可以先兼顧開發效率；當系統複雜度提高時，又有足夠的結構可以逐步抽離 Domain Logic、調整 Service Boundary，而不必整套推翻重來。
這整段討論，對我來說才是目前與 AI 協作最有價值的地方。
不是：
「AI，直接幫我把這個問題解決掉。」
而是：
我提出多年開發經驗形成的直覺，AI 用既有的架構原則挑戰它；我再根據實際系統規模提出取捨，最後雙方把模糊的經驗整理成更明確、可以落地的設計準則。
這種互動不只是提高開發效率。
它其實也在迫使自己重新回答：
「我以前一直這樣設計，但為什麼？」
「這是原則，還是只是習慣？」
「什麼情況下應該遵守？什麼情況下反而應該簡化？」
我覺得這才是 AI 時代對資深開發者很有意思的一種學習方式。
不是把思考交給 AI，而是利用 AI，把自己的思考磨得更清楚。
我也把這次與 AI 討論後形成的 Application Layer Design 共識整理成一份文件作為範本：
🔗 https://reurl.cc/mzpZb9
這份文件不只是討論紀錄，而是把設計取捨整理成可以持續引用、檢視與調整的開發規範。
對正在思考如何導入分層架構、Application Layer、Repository、Domain Logic Placement，或想採用較務實 Simplified DDD 的開發者來說，應該具有相當的參考價值。