技能 architecture-patterns
🥉 73 青銅
1
下載技能 ZIP
2
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
3
開啟並開始使用
測試它
正在使用「architecture-patterns」。 為使用者管理系統設計潔淨架構結構
預期結果:
- 第 1 層：領域 - 具有商業規則的使用者實體（啟用、驗證）
- 第 2 層：使用案例 - CreateUser、UpdateUser、DeactivateUser
- 第 3 層：介面調適器 - UserController、UserPresenter
- 第 4 層：基礎設施 - PostgresUserRepository、RedisCache
正在使用「architecture-patterns」。 解釋實體和值物件之間的差異
預期結果:
- 實體：具有身分識別、可變、以 ID 判斷相等性（例如：Order、User）
- 值物件：無身分識別、不可變、以屬性判斷相等性（例如：Email、Money、Address）
安全審計
安全v1 • 2/24/2026
Static analysis flagged 32 potential issues including external_commands, env_access, and weak cryptographic algorithms. After evaluation, all findings are FALSE POSITIVES. The skill contains only documentation and Python code examples for software architecture patterns. No actual command execution, cryptographic code, or secret access exists. The flagged patterns are innocent uses of architecture terminology (domain, ports, adapters) and placeholder interface definitions.
2
已掃描檔案
520
分析行數
3
發現項
1
審計總數
高風險問題 (1)
False Positive: env_access Pattern
Static scanner flagged 'api_key' parameter in StripePaymentAdapter as env_access. This is a legitimate interface definition, not actual secret access. The code only defines type signatures for a payment adapter.
中風險問題 (1)
False Positive: external_commands Pattern
Static scanner detected 'Ruby/shell backtick execution' but the files contain only Python code examples and markdown documentation. No backtick shell execution exists.
低風險問題 (1)
False Positive: System Reconnaissance
Static scanner flagged 'domain' and 'bounded context' as system reconnaissance. These are legitimate Domain-Driven Design (DDD) terminology, not system reconnaissance.
審計者: claude
品質評分
38
架構
100
可維護性
87
內容
50
社群
88
安全
100
規範符合性
你能建構什麼
建構新後端系統架構
使用潔淨架構設計新的後端服務，包含適當的層次分離和依賴規則。
重構單一應用程式程式碼庫
將緊密耦合的程式碼遷移至具有清晰連接埠和調適器的六邊形架構。
應用 DDD 戰術模式
使用實體、值物件和聚合為複雜商業領域實作領域模型。
試試這些提示
基礎架構設計
協助我為電子商務應用程式設計潔淨架構結構。我應該建立哪些層次，它們之間的依賴關係為何？
六邊形架構設定
展示如何使用六邊形架構實作支付服務。包含連接埠和調適器，並附上 Stripe 範例。
領域驅動設計模型
為訂單管理系統建立 DDD 領域模型。包含實體、值物件、聚合和領域事件。
架構遷移計畫
最佳實務
- 將商業邏輯保持在領域層，獨立於框架之外
- 在實作調適器之前定義清晰的介面（連接埠）
- 確保內層完全不知道外層的實作細節
避免
- 將商業邏輯放入控制器（肥胖控制器）
- 將領域邏輯與基礎設施程式碼混合
- 建立沒有行為的貧血領域模型
常見問題
我應該何時使用潔淨架構？
對於測試性和可維護性為優先考量的複雜後端系統，使用潔淨架構。它會增加初始開銷，因此簡單的 CRUD 應用程式應避免使用。
六邊形架構的主要優勢為何？
它讓您可以輕鬆交換實作。您可以在測試時使用模擬支付調適器，並在生產環境切換至 Stripe，而無需變更領域邏輯。
領域驅動設計與潔淨架構有何不同？
DDD 專注於使用邊界上下文和通用語言建模複雜商業領域。潔淨架構是一種技術結構，可以搭配或不搭配 DDD 使用。
我可以將此技能用於任何程式語言嗎？
可以，這些模式與程式語言無關。範例使用 Python，但這些原則適用於任何物件導向語言。
什麼是值物件，我應該何時使用它們？
值物件是不可變的物件，由其屬性而非身分識別定義。當相等性比身分識別更重要時使用它們，例如金錢、電子郵件或地址等概念。
我該如何開始遷移舊有程式碼庫？
首先識別領域邊界。以目標架構建立新程式碼，同時保留舊有程式碼。以功能為單位逐步遷移。