設計開發 | Eric 個人部落格

資料庫設計指引範本 Prompt 目標指導 AI 進行資料庫設計，建立結構化、高效能且可維護的資料庫架構。角色設定你是一位資深資料庫設計師，具備豐富的資料庫設計經驗，熟悉正規化理論、效能優化和資料安全設計。任務描述請協助我完成 {專案名稱} 的資料庫設計工作。專案資料庫背景專案名稱: {填入專案名稱} 資料庫類型: {填入資料庫類型，如：MySQL, PostgreSQL, MongoDB} 資料量規模: {填入預估資料量} 併發需求: {填入併發使用者數量} 效能要求: {填入效能指標} 可用性要求: {填入可用性需求} 資料庫設計要求請按照以下結構進行設計： 1. 概念模型設計實體識別屬性定義關係建立業務規則定義 2. 邏輯模型設計正規化設計資料類型選擇約束條件定義索引策略規劃 3. 實體模型設計表格結構設計主鍵和外鍵設計觸發器和預存程序權限和安全設計 4. 效能優化設計索引最佳化查詢優化分割策略快取策略 5. 資料安全設計存取控制資料加密稽核記錄備份恢復輸出格式 # {專案名稱} 資料庫設計文件 ## 1. 資料庫概述 ### 1.1 設計目標 **功能目標:** - 支援 {具體業務功能} - 處理 {資料處理需求} - 提供 {資料服務能力} **效能目標:** - 查詢響應時間: < {時間閾值} - 併發處理能力: {併發數量} - 資料處理量: {處理量指標} - 可用性: {可用性百分比} ### 1.2 技術選型 #### 主要資料庫: {資料庫名稱} **選擇理由:** - 符合資料特性和查詢模式 - 滿足效能和擴展性需求 - 團隊技術熟悉度 - 生態系統支援 **版本:** {資料庫版本} **配置:** {主要配置參數} #### 補充技術 - **快取系統:** {如 Redis, Memcached} - **搜尋引擎:** {如 Elasticsearch} - **時序資料庫:** {如 InfluxDB} - **圖形資料庫:** {如 Neo4j} ### 1.3 資料庫架構 #### 整體架構圖 ```mermaid graph TB App[應用程式] --> Pool[連線池] Pool --> Master[主資料庫] Pool --> Slave1[從資料庫1] Pool --> Slave2[從資料庫2] Master --> Replication[主從複製] Replication --> Slave1 Replication --> Slave2 App --> Cache[快取層] Cache --> Redis[Redis 叢集] Master --> Backup[備份系統] Backup --> S3[雲端儲存] 2. 概念模型設計 2.1 實體識別核心實體清單實體1: {實體名稱} ...

軟體架構設計指引範本 Prompt 目標指導 AI 進行軟體系統架構設計，建立可擴展、可維護且符合業務需求的技術架構。角色設定你是一位資深軟體架構師，具備豐富的系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。任務描述請協助我完成 {專案名稱} 的軟體架構設計工作。專案架構背景專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 技術棧: {填入主要技術棧} 預期使用者規模: {填入預估使用者數量} 效能需求: {填入效能指標} 可用性需求: {填入可用性要求} 擴展性需求: {填入擴展性要求} 架構設計要求請按照以下結構進行設計： 1. 整體架構設計系統架構風格選擇主要組件識別層級架構設計部署架構規劃 2. 組件設計核心組件定義組件間關係介面設計責任分離 3. 資料架構資料模型設計資料流設計儲存策略快取策略 4. 安全架構認證和授權資料安全通訊安全威脅建模 5. 效能架構效能優化策略負載平衡快取機制資源管理 6. 可靠性設計錯誤處理容錯機制監控和日誌災難恢復輸出格式 # {專案名稱} 軟體架構設計文件 ## 1. 架構概述 ### 1.1 系統概述 **系統名稱:** {專案名稱} **系統類型:** {系統類型描述} **主要功能:** {核心功能清單} **技術棧:** {使用的技術列表} ### 1.2 架構目標 **品質屬性優先級:** 1. **可用性** - 目標: 99.9% uptime 2. **效能** - 目標: 響應時間 < 200ms 3. **擴展性** - 目標: 支援 10x 使用者增長 4. **安全性** - 目標: 符合 OWASP 安全標準 5. **可維護性** - 目標: 新功能開發週期 < 2週 ### 1.3 約束和假設 **技術約束:** - 必須使用 {指定技術} - 須符合 {合規要求} - 預算限制: {預算範圍} **業務約束:** - 上線時間: {時間限制} - 團隊規模: {開發團隊大小} - 維運資源: {維運能力說明} ## 2. 整體架構設計 ### 2.1 架構風格選擇 #### 選擇的架構風格: {架構風格名稱} **原因說明:** - 符合系統規模和複雜度 - 滿足效能和擴展性需求 - 團隊技術能力匹配 - 維運成本可控 #### 替代方案比較 | 架構風格 | 優點 | 缺點 | 適用場景 | 選擇結果 | |----------|------|------|----------|----------| | 單體架構 | 簡單、快速開發 | 擴展性限制 | 小型系統 | ❌ | | 微服務架構 | 可擴展、技術多樣性 | 複雜度高 | 大型系統 | ✅ | | 無伺服器 | 免維運、彈性擴展 | 冷啟動、供應商綁定 | 事件驅動 | ❌ | ### 2.2 系統架構圖 ```mermaid graph TB User[使用者] --> LB[負載平衡器] LB --> API[API Gateway] API --> Auth[認證服務] API --> BFF[Backend for Frontend] BFF --> UserSvc[使用者服務] BFF --> ProductSvc[產品服務] BFF --> OrderSvc[訂單服務] BFF --> PaymentSvc[支付服務] UserSvc --> UserDB[(使用者資料庫)] ProductSvc --> ProductDB[(產品資料庫)] OrderSvc --> OrderDB[(訂單資料庫)] PaymentSvc --> PaymentDB[(支付資料庫)] OrderSvc --> Queue[訊息佇列] Queue --> EmailSvc[郵件服務] Queue --> NotificationSvc[通知服務] UserSvc --> Cache[Redis 快取] ProductSvc --> Cache UserSvc --> Log[日誌系統] ProductSvc --> Log OrderSvc --> Log PaymentSvc --> Log 2.3 部署架構環境規劃開發環境: ...