技能 software-architecture
🏗️

software-architecture

安全

建構可擴展的軟體架構

也可从以下获取: Doyajin174,Chemiseblanc

停止使用自訂的 utility 和 helper 重新發明輪子。此技能教授 Clean Architecture 和領域驅動設計原則,協助您撰寫可維護、可擴展的程式碼。

支持: Claude Codex Code(CC)
🥉 75 青铜
1

下载技能 ZIP

2

在 Claude 中上传

前往 设置 → 功能 → 技能 → 上传技能

3

开启并开始使用

测试它

正在使用“software-architecture”。 審查此 UserService 類別的架構問題:[ UserService 類別將資料庫查詢、API 呼叫和 UI 渲染全部混合在一起 ]

预期结果:

發現的架構問題:1) 混合關注點 - 資料庫查詢應屬於 Repository 層,2) UI 渲染應在獨立的 view 元件中,3) API 呼叫應在專用的 service 中。建議重構:拆分為 UserRepository(資料)、UserService(業務邏輯)和 UserView(呈現)。

正在使用“software-architecture”。 我需要實作付款處理。應該自己建構還是使用函式庫?

预期结果:

建議:使用 Stripe 或 Paddle 而非建構自訂的付款處理。這些服務處理 PCI 合規性、定期計費、webhooks 和邊緣情況,這些需要數月時間才能自行建構。只有在現有解決方案無法滿足您的特殊需求時,才考慮自訂實作。

正在使用“software-architecture”。 為電子商務應用程式設計訂單處理模組

预期结果:

建議架構 (DDD):1) Order 實體(領域):Order、OrderItem、OrderStatus。2) 儲存庫:OrderRepository、InventoryRepository。3) 服務:OrderService(placeOrder、cancelOrder)、PaymentService(processPayment)、InventoryService(reserveItems)。4) 應避免的反模式:OrderController 執行業務邏輯、controller 中的資料庫查詢、通用的 OrderUtils 類別。

安全审计

安全
v1 • 2/25/2026

All static analysis findings are false positives. Detected 'backtick execution' patterns are markdown code emphasis formatting for library names and file examples. 'Weak cryptographic algorithm' detections are references to 'Clean Architecture' design pattern, not cryptography. 'System reconnaissance' patterns match legitimate software development guidance. This skill contains no executable code and provides educational architecture guidance only.

1
已扫描文件
81
分析行数
0
发现项
1
审计总数
未发现安全问题
审计者: claude

质量评分

38
架构
100
可维护性
87
内容
50
社区
100
安全
100
规范符合性

你能构建什么

全新專案架構

啟動新專案,需要從第一天建立稳固的架構基礎

重構舊有程式碼

應用 clean architecture 原則改善現有程式碼庫的程式碼品質

程式碼���查標準

為團隊程式碼審查和 pull requests 建立一致的架構指導原則

试试这些提示

審查我的程式碼結構
審查這個程式碼元件的架構問題。檢查:通用命名(utils/helpers)、業務邏輯與 UI 混合、檔案長度超過 200 行、函式超過 50 行。建議遵循 Clean Architecture 原則的改進方案。
設計模組架構
我需要建構一個 [feature] 模組。遵循 DDD 原則設計架構。為實體、服務和儲存庫建議領域特定的名稱。定義清晰的邊界和關注點分離。
尋找更好的函式庫解決方案
我需要實作 [feature] 功能。搜尋解決此問題的現有函式庫或服務。基於以下條件評估選項:維護狀態、社群採用度、文件品質,以及符合我的需求。
重構反模式
分析此程式碼庫的架構反模式:NIH 症候群(自訂實作而非使用函式庫)、通用檔案名稱、關注點分離不佳、深層嵌套。提供具體的重構建議和範例。

最佳实践

  • 在撰寫自訂程式碼之前搜尋現有的函式庫和服務,以減少維護負擔
  • 使用領域特定的名稱如 OrderCalculator 和 UserAuthenticator,而非通用的 utils 或 helpers
  • 保持業務邏輯獨立於框架,並與 UI 元件��離
  • 應用提前返回模式以減少嵌套並改善程式碼可讀性

避免

  • 建立包含不相關函式的 utils.js 或 helpers.ts 檔案,而非領域特定的模組
  • 將業務邏輯與 UI 元件混合,或將資��庫查詢直接放在 controller 中
  • 當既有函式庫存在時,仍建構自訂的驗證、狀態管理或表單驗證
  • 使用通用名稱(common、shared、misc)命名檔案或模組,而無清晰的領域目的

常见问题

什麼是 Clean Architecture?
Clean Architecture 是一種軟體設計模式,將關注點分離到不同的層級:領域實體(業務規則)、用例(應用程式規則)、介面卡(controllers、presenters)和框架(UI、資料庫)。這種獨立性使您的程式碼可測試且靈活。
為什麼要避免使用 utils 和 helpers 檔案?
通用的 utils 和 helpers 會成為不相關程式碼的傾倒場。它們缺乏清晰的目的,且變得難以維護。領域特定的名稱如 OrderCalculator 或 EmailValidator 能傳達意圖,並按業務上下文組織程式碼。
何時應該撰寫自訂程式碼而非使用函式庫?
僅在以下情況撰寫自訂程式碼:獨特的業務邏輯、有特殊需求的高效能關鍵路徑、需要完全控制的安全敏感程式碼,或在徹底評估後現有解決方案確實無法滿足您的需求時。
建議的檔案大小限制是多少?
盡可能保持函式在 50 行以內,檔案在 200 行以內。將較長的元件分解為更小、更聚焦的部分。如果程式碼無法在其他地方重複使用,則將其保留在同一個檔案中,直到為了可維護性而需要拆分。
此技能與一般程式碼助理有何不同?
此技能專注於架構決策和程式碼組織,而非語法或實作細節。它指導高階結構、設計模式和可維護性,而非撰寫特定演算法或修復錯誤。
我可以將此技能用於任何程式語言嗎?
可以。架構原則(Clean Architecture、DDD、關注點分離)適用於所有語言。然而,實作細節因語言和框架而異,因此請根據您的特定技術堆疊調整建議。

开发者详情

文件结构

📄 SKILL.md