Fastify 5 Boilerplate：把 DDD 與 CQRS 放進垂直切片
Fastify 5 應用程式樣板基於乾淨的架構、領域驅動設計、CQRS、函數式程式設計、垂直切片架構，用於建立生產級應用程式。
秒懂
- 它是什麼？
- Fastify 5 Boilerplate：把 DDD 與 CQRS 放進垂直切片。本文聚焦 README 明確列出的元件、使用入口與驗收邊界。
- 適合誰用？
- 適合需要 Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 所描述工作流、且能維護相依環境的團隊；不適合把 README 介紹當作完整生產保證的情境。先照 marcoturi/fastify-boilerplate 的專案入口完成最小案例，記錄命令輸出、版本與專案專屬檔案，再決定是否擴大使用。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月14日）與我們的分析，不構成法律意見。
開源專案深度解析
marcoturi，marcoturi，marcoturi/fastify-boilerplate 解決的具體問題
marcoturi/fastify-boilerplate 的 README 將它定位為「Fastify 5 application boilerplate based on clean architecture, domain-driven design, CQRS, functional programming, vertical slice architecture for building production-grade applications.」。本文只整理來源明確寫出的設計、入口與限制。素材顯示專案使用 TypeScript，公開統計為約 461 個 star；這些是倉庫資料，不代表本文親自測得的速度、穩定性或相容性。README 的實際線索包括：[](https://biomejs.dev/) [](http://commitizen.github.io/cz-cli/) [](https://github.com/marcoturi/fastify-boilerplate/blob/main/LICENSE) A production-ready [Fastify 5](https://github.com/fastify/fastify) boilerplate built on Clean Architecture, CQRS, DDD, and functional programming. Designed as a starting point for real-world applications, the architecture is framework-agnostic at its core ， the patterns and boundaries translate to any language or framework. Table of Contents - [Features](features) - [Prerequisites](prerequisites) - [Getting Started](getting-started) - [Available Scripts](available-scripts) - [Running with Docker](running-with-docker) - [API Endpoints](api-endpoints) - [Architecture](architecture) - [Principles](principles) - [Modules](modules) - [Module Components](module-components) - [Folder Structure](folder-structure) - [OpenTelemetry](opentelemetry) - [Testing](testing) - [Client Types Package](client-types-package) - [CI/CD Pipeline](cicd-pipeline) - [AI-Assisted Development](ai-assisted-development) - [Why Biome over ESLint + Prettier?](why-biome-over-eslint--prettier) - [Useful Resources](useful-resources) - [Contributing](contributing) - [License](license) Features Category Details ------ Runtime Native TypeScript via [Node.js = 24](https://nodejs.org/en/blog/release/v24.0.0) type stripping ， no build step, no transpiler Framework [Fastify 5](https://github.com/fastify/fastify) with [Awilix](https://github.com/jeffijoe/awilix) DI and [Pino](https://github.com/pinojs/pino) logging API REST ([TypeBox](https://github.com/sinclairzx81/typebox) schemas, Swagger UI) + GraphQL ([Mercurius](https://github.com/mercurius-js/mercurius), GraphiQL in dev) Database [Postgres.js](https://github.com/porsager/postgres) client + [DBMate](https://github.com/amacneil/dbmate) migrations & seeds Security [@fastify/helmet](https://github.com/fastify/fastify-helmet), [@fastify/under-pressure](https://github.com/fastify/under-pressure) for back-pressure Telemetry Vendor-agnostic [OpenTelemetry](https://opentelemetry.io/) with auto-instrumentation (disabled by default) Linting [Biome](https://biomejs.dev/) ， single tool for linting, formatting, and import sorting Architecture [dependency-cruiser](https://github.com/sverweij/dependency-cruiser) validates layer boundaries at CI time Release [Husky](https://github.com/typicode/husky) + [Commitlint](https://commitlint.js.org/) + [Semantic Release](https://github.com/semantic-release/sem
選型時先問工作流是否真的需要 Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker。若需求只是單一小功能，完整專案的設定與依賴可能比手寫整合更重；若需求正好落在 README 描述的範圍，專案提供的命名與範例可成為可讀的入口。文件未說明的行為，不應從描述或 star 數推論。
在「marcoturi/fastify-boilerplate 解決的具體問題」這一層，還要把 marcoturi/fastify-boilerplate 的名稱、Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 與實際輸入輸出放在同一份紀錄裡。先用最小資料量和單一設定跑一次，再逐項增加複雜度，才能知道問題是由哪個元件引入。當命令成功但畫面、檔案或 API 結果不對時，應回到對應的 README 小節和專案路徑比對，而不是只看程序是否結束。
marcoturi，marcoturi，核心元件如何分工
從 README 可辨識的核心名稱是 Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker。它們各自承擔不同邊界，不能把展示層、執行層、資料層或代理協調層混成一個功能。閱讀原始碼時，先以這些名稱搜尋註冊點、入口檔和測試，再追實際資料流。若某名稱只出現在介紹文字而沒有範例，應標成待確認，而不是當作穩定 API。
這種分工對維護很重要：修改一個元件時，應觀察相鄰元件是否共享狀態、設定或輸出格式。README 沒有交代的生命週期、併發量與錯誤恢復方式，本文不替專案補上保證。
在「核心元件如何分工」這一層，還要把 marcoturi/fastify-boilerplate 的名稱、Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 與實際輸入輸出放在同一份紀錄裡。先用最小資料量和單一設定跑一次，再逐項增加複雜度，才能知道問題是由哪個元件引入。當命令成功但畫面、檔案或 API 結果不對時，應回到對應的 README 小節和專案路徑比對，而不是只看程序是否結束。
marcoturi，marcoturi，README 入口與實際使用邊界
README 提供的入口集中在 Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker。建議把它們視為不同層次的證據：安裝命令只能證明依賴能被取得，範例只能說明示範路徑，文件和測試才可能補充介面細節。對 marcoturi/fastify-boilerplate 而言，首次閱讀應沿著 README 的目錄、範例與相關檔案走，不要先把所有選項一次加入自己的系統。
若專案涉及外部服務、GPU、瀏覽器、資料庫或訊息平台，這些環境條件要單獨記錄。來源沒有提供完整矩陣時，結論只能限縮為「README 描述的使用情境值得試」，不能延伸成通用生產承諾。
在「README 入口與實際使用邊界」這一層，還要把 marcoturi/fastify-boilerplate 的名稱、Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 與實際輸入輸出放在同一份紀錄裡。先用最小資料量和單一設定跑一次，再逐項增加複雜度，才能知道問題是由哪個元件引入。當命令成功但畫面、檔案或 API 結果不對時，應回到對應的 README 小節和專案路徑比對，而不是只看程序是否結束。
marcoturi，marcoturi，一個可重現的最小驗收
針對 marcoturi/fastify-boilerplate，先準備乾淨目錄並照 README 執行 Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker。每一步保存命令輸出、依賴版本與產生的檔案。驗收觀察點要貼近專案：確認入口是否啟動、核心元件是否收到預期輸入、輸出是否符合 README 範例，並記下 Console、終端或測試失敗訊息。
若結果與文件不同，先區分環境差異、版本差異和程式錯誤。不要以一次成功掩蓋重跑失敗，也不要把沒有被 README 提及的功能列為已支援。這樣的記錄才足以判斷它是否適合目前的工作流。
在「一個可重現的最小驗收」這一層，還要把 marcoturi/fastify-boilerplate 的名稱、Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 與實際輸入輸出放在同一份紀錄裡。先用最小資料量和單一設定跑一次，再逐項增加複雜度，才能知道問題是由哪個元件引入。當命令成功但畫面、檔案或 API 結果不對時，應回到對應的 README 小節和專案路徑比對，而不是只看程序是否結束。
marcoturi，marcoturi，版本、授權與維護判斷
素材顯示 marcoturi/fastify-boilerplate 的授權欄位為「MIT」，但授權文字本身仍應以倉庫 LICENSE 為準。若要把程式碼放入商業產品，需保留版權與授權聲明，並檢查相依套件的條件；授權不等於作者對相容性或支援期限的承諾。
專案最近更新時間、issue 數和 release 標籤都應與目前 checkout 的 commit 分開記錄。本文素材沒有提供完整維護 SLA，因此升級時要重新跑 Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 相關驗收，尤其是設定鍵、命令列介面和輸出格式。
在「版本、授權與維護判斷」這一層，還要把 marcoturi/fastify-boilerplate 的名稱、Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 與實際輸入輸出放在同一份紀錄裡。先用最小資料量和單一設定跑一次，再逐項增加複雜度，才能知道問題是由哪個元件引入。當命令成功但畫面、檔案或 API 結果不對時，應回到對應的 README 小節和專案路徑比對，而不是只看程序是否結束。
marcoturi，marcoturi，適合的團隊與不適合的情境
Fastify 5 Boilerplate：把 DDD 與 CQRS 放進垂直切片 適合已經使用 README 所指技術、願意閱讀專案邊界並能維護其依賴的開發者。它不適合把介紹頁當成完整規格，或需要來源未承諾的高可用、跨平台矩陣與長期支援的團隊。對 marcoturi/fastify-boilerplate，最有價值的下一步是縮小到一個真實案例，讓 Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 在你的資料與權限條件下留下可比較的結果。
若最小案例需要大量繞路、文件缺少關鍵設定，或輸出無法被現有流程接收，這就是停止擴大導入的具體訊號。反之，若範例、測試與實際輸出一致，再評估是否建立包裝層、固定版本與維護責任。
在「適合的團隊與不適合的情境」這一層，還要把 marcoturi/fastify-boilerplate 的名稱、Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 與實際輸入輸出放在同一份紀錄裡。先用最小資料量和單一設定跑一次，再逐項增加複雜度，才能知道問題是由哪個元件引入。當命令成功但畫面、檔案或 API 結果不對時，應回到對應的 README 小節和專案路徑比對，而不是只看程序是否結束。
編輯結論
適合需要 Node.js = 24、Fastify 5、Biome、TypeBox、Postgres、OpenTelemetry、Docker 所描述工作流、且能維護相依環境的團隊；不適合把 README 介紹當作完整生產保證的情境。先照 marcoturi/fastify-boilerplate 的專案入口完成最小案例，記錄命令輸出、版本與專案專屬檔案，再決定是否擴大使用。
社群筆記