為什麼需要好的專案架構？

在前面幾天的學習裡，我們慢慢累積了越來越多的 Terraform 配置。其實就跟開發應用程式一樣，如果一開始沒有好好設計架構，隨著功能與需求的增加，原本簡單的程式碼就會慢慢變得複雜，最後難以維護。

一開始或許只是一個 main.tf 就能搞定所有事情，但隨著專案規模變大，你會發現檔案不斷膨脹，最後變成一個誰也不敢隨便動的巨石檔案：

# 混亂的專案結構
my-terraform-project/
├── main.tf (300+ 行)
├── variables.tf (50+ 個變數)
├── random-vm-config.tf
├── network-stuff.tf
├── backup-main.tf
└── old-config-dont-delete.tf

這樣的結構在個人練習時或許勉強能用，但一旦放到團隊專案，就會出現很多問題：

• 難以理解：新成員需要花數天時間才能找到某個配置放在哪裡
• 容易出錯：不同功能混在一起，改一個地方可能影響其他資源
• 協作困難：多人同時修改 main.tf，衝突頻繁，合併痛苦
• 缺乏一致性：沒有命名規範，整個專案看起來零散又難維護

這就是為什麼我們需要一個 清晰、有條理的專案架構。它不僅讓程式碼變得乾淨，還能幫助團隊快速上手、降低維護成本。

基礎檔案組織原則

標準檔案拆分

Terraform 社群普遍建議的基本結構如下：

project/
├── main.tf          # 主要資源定義
├── variables.tf     # 輸入變數
├── outputs.tf       # 輸出值
├── providers.tf     # Provider 配置
├── terraform.tf     # Terraform 設定與 Backend
└── versions.tf      # 版本約束

這樣拆分後，每個檔案的角色清楚：要找 Provider 就去 providers.tf，要看版本限制就去 versions.tf，降低了理解和維護成本。

按功能分類

如果專案資源很多，可以進一步依照功能領域拆分，例如：

# network.tf - 網路相關資源
resource "google_compute_network" "vpc" { ... }
resource "google_compute_subnetwork" "subnet" { ... }

# compute.tf - 計算資源
resource "google_compute_instance" "app" { ... }

# storage.tf - 儲存資源
resource "google_storage_bucket" "data" { ... }

這樣當你想修改防火牆規則時，就直接去 network.tf，不用在 300 行的 main.tf 中翻來翻去。

專案結構設計的進階思維

當專案從「小型練習」成長為「企業級基礎設施」時，就需要更嚴謹的架構。這裡我們不會深入 Workspaces 細節（明天會聊到），但可以先了解一些組織思維。

區分核心模組與專案配置

一個健康的架構，通常會將「核心模組」與「專案配置」分開：

terraform-infrastructure/
├── modules/         # 模組：可重用的基礎建設單位
│   ├── networking/
│   ├── compute/
│   └── database/
└── project/         # 專案：實際調用模組，組合出完整架構
    ├── main.tf
    ├── variables.tf
    └── outputs.tf

• modules/：像積木，定義好一個個可重複使用的功能（VPC、VM、Database）。
• project/：像拼圖，依照需求把模組組合起來，成為完整環境。

這樣的好處是模組可以被多個專案重用，而不是每個專案都要重新寫一份。

環境分離的初步概念

大型專案通常會有 開發、測試、正式 等不同環境。

在今天的內容裡，我們只需要先理解一個原則：環境應該有清楚的邊界。

例如：

project/
├── dev/
├── staging/
└── prod/

每個環境都有自己的配置與參數檔，不會互相干擾。
至於要如何透過 Terraform 的 Workspaces 來管理這些環境，我們明天會實戰練習到。

命名與組織規範

好的架構除了檔案分類，也需要一致的命名規則。

檔案命名

• 小寫 + 連字號：app-server.tf
• 依功能分類：network.tf, compute.tf, storage.tf
• 版本專屬檔案：集中在 versions.tf

變數整理

# variables.tf - 依類別整理
# === 基本配置 ===
variable "project_id" { ... }
variable "region" { ... }

# === 網路配置 ===
variable "vpc_cidr" { ... }

# === 應用配置 ===
variable "app_instance_count" { ... }

當變數愈多，這種分組方式就能大幅降低混亂。

總結一下

在專案的成長過程中，架構也會隨之進化。最初我們可能只需要一個 main.tf，就能把所有資源堆在一起完成練習。但當規模慢慢擴大，就會發現這樣的方式不再好維護，於是開始依功能拆分，例如把網路、運算、儲存等資源各自放進不同的檔案中。等到專案再更上一層樓，進入多人協作或跨環境部署的階段，就必須走向模組化設計，並搭配清楚的檔案規範與資料夾結構，讓整個專案既穩定又容易被他人理解。

這裡有幾個不變的原則，無論專案大小都適用：保持分層清楚，讓模組與專案層級各司其職；確保每個檔案的責任單一，避免混亂；使用一致的命名方式，降低溝通成本；並撰寫完整的文件，讓新加入的成員能快速上手。

🐈🐈🐈

明天，我們將把今天談到的專案結構真正落地，實際操作 Workspaces 多環境管理（dev/test/prod 實戰）。透過這個練習，可以看到如何將相同的架構套用在不同環境，同時保持彈性與一致性，讓專案從設計走向真正可運行的部署流程！