[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-d17c330f-cc7c-47be-9045-cd3712e4dd81":3,"$ffG_AUtjxvNzs8i8QJPrO7qeha43lgbT_RCRvMgRe2WU":42},{"id":4,"title":5,"description":6,"categoryId":7,"moduleId":8,"tags":9,"prompt":10,"icon":11,"source":12,"sourceUrl":13,"authorId":14,"authorName":15,"isPublic":16,"stars":17,"runs":18,"createdAt":19,"updatedAt":19,"module":20,"category":27,"packages":33},"d17c330f-cc7c-47be-9045-cd3712e4dd81","architecture-decision-records","创建、维护和管理捕获重要技术决策背景和理由的架构决策记录（ADRs）的综合模式。","cat_coding_backend","mod_coding","sickn33,coding","---\nname: architecture-decision-records\ndescription: \"Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.\"\nrisk: unknown\nsource: community\ndate_added: \"2026-02-27\"\n---\n\n# Architecture Decision Records\n\nComprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.\n\n## Use this skill when\n\n- Making significant architectural decisions\n- Documenting technology choices\n- Recording design trade-offs\n- Onboarding new team members\n- Reviewing historical decisions\n- Establishing decision-making processes\n\n## Do not use this skill when\n\n- You only need to document small implementation details\n- The change is a minor patch or routine maintenance\n- There is no architectural decision to capture\n\n## Instructions\n\n1. Capture the decision context, constraints, and drivers.\n2. Document considered options with tradeoffs.\n3. Record the decision, rationale, and consequences.\n4. Link related ADRs and update status over time.\n\n## Core Concepts\n\n### 1. What is an ADR?\n\nAn Architecture Decision Record captures:\n- **Context**: Why we needed to make a decision\n- **Decision**: What we decided\n- **Consequences**: What happens as a result\n\n### 2. When to Write an ADR\n\n| Write ADR | Skip ADR |\n|-----------|----------|\n| New framework adoption | Minor version upgrades |\n| Database technology choice | Bug fixes |\n| API design patterns | Implementation details |\n| Security architecture | Routine maintenance |\n| Integration patterns | Configuration changes |\n\n### 3. ADR Lifecycle\n\n```\nProposed → Accepted → Deprecated → Superseded\n              ↓\n           Rejected\n```\n\n## Templates\n\n### Template 1: Standard ADR (MADR Format)\n\n```markdown\n# ADR-0001: Use PostgreSQL as Primary Database\n\n## Status\n\nAccepted\n\n## Context\n\nWe need to select a primary database for our new e-commerce platform. The system\nwill handle:\n- ~10,000 concurrent users\n- Complex product catalog with hierarchical categories\n- Transaction processing for orders and payments\n- Full-text search for products\n- Geospatial queries for store locator\n\nThe team has experience with MySQL, PostgreSQL, and MongoDB. We need ACID\ncompliance for financial transactions.\n\n## Decision Drivers\n\n* **Must have ACID compliance** for payment processing\n* **Must support complex queries** for reporting\n* **Should support full-text search** to reduce infrastructure complexity\n* **Should have good JSON support** for flexible product attributes\n* **Team familiarity** reduces onboarding time\n\n## Considered Options\n\n### Option 1: PostgreSQL\n- **Pros**: ACID compliant, excellent JSON support (JSONB), built-in full-text\n  search, PostGIS for geospatial, team has experience\n- **Cons**: Slightly more complex replication setup than MySQL\n\n### Option 2: MySQL\n- **Pros**: Very familiar to team, simple replication, large community\n- **Cons**: Weaker JSON support, no built-in full-text search (need\n  Elasticsearch), no geospatial without extensions\n\n### Option 3: MongoDB\n- **Pros**: Flexible schema, native JSON, horizontal scaling\n- **Cons**: No ACID for multi-document transactions (at decision time),\n  team has limited experience, requires schema design discipline\n\n## Decision\n\nWe will use **PostgreSQL 15** as our primary database.\n\n## Rationale\n\nPostgreSQL provides the best balance of:\n1. **ACID compliance** essential for e-commerce transactions\n2. **Built-in capabilities** (full-text search, JSONB, PostGIS) reduce\n   infrastructure complexity\n3. **Team familiarity** with SQL databases reduces learning curve\n4. **Mature ecosystem** with excellent tooling and community support\n\nThe slight complexity in replication is outweighed by the reduction in\nadditional services (no separate Elasticsearch needed).\n\n## Consequences\n\n### Positive\n- Single database handles transactions, search, and geospatial queries\n- Reduced operational complexity (fewer services to manage)\n- Strong consistency guarantees for financial data\n- Team can leverage existing SQL expertise\n\n### Negative\n- Need to learn PostgreSQL-specific features (JSONB, full-text search syntax)\n- Vertical scaling limits may require read replicas sooner\n- Some team members need PostgreSQL-specific training\n\n### Risks\n- Full-text search may not scale as well as dedicated search engines\n- Mitigation: Design for potential Elasticsearch addition if needed\n\n## Implementation Notes\n\n- Use JSONB for flexible product attributes\n- Implement connection pooling with PgBouncer\n- Set up streaming replication for read replicas\n- Use pg_trgm extension for fuzzy search\n\n## Related Decisions\n\n- ADR-0002: Caching Strategy (Redis) - complements database choice\n- ADR-0005: Search Architecture - may supersede if Elasticsearch needed\n\n## References\n\n- [PostgreSQL JSON Documentation](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fdatatype-json.html)\n- [PostgreSQL Full Text Search](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Ftextsearch.html)\n- Internal: Performance benchmarks in `\u002Fdocs\u002Fbenchmarks\u002Fdatabase-comparison.md`\n```\n\n### Template 2: Lightweight ADR\n\n```markdown\n# ADR-0012: Adopt TypeScript for Frontend Development\n\n**Status**: Accepted\n**Date**: 2024-01-15\n**Deciders**: @alice, @bob, @charlie\n\n## Context\n\nOur React codebase has grown to 50+ components with increasing bug reports\nrelated to prop type mismatches and undefined errors. PropTypes provide\nruntime-only checking.\n\n## Decision\n\nAdopt TypeScript for all new frontend code. Migrate existing code incrementally.\n\n## Consequences\n\n**Good**: Catch type errors at compile time, better IDE support, self-documenting\ncode.\n\n**Bad**: Learning curve for team, initial slowdown, build complexity increase.\n\n**Mitigations**: TypeScript training sessions, allow gradual adoption with\n`allowJs: true`.\n```\n\n### Template 3: Y-Statement Format\n\n```markdown\n# ADR-0015: API Gateway Selection\n\nIn the context of **building a microservices architecture**,\nfacing **the need for centralized API management, authentication, and rate limiting**,\nwe decided for **Kong Gateway**\nand against **AWS API Gateway and custom Nginx solution**,\nto achieve **vendor independence, plugin extensibility, and team familiarity with Lua**,\naccepting that **we need to manage Kong infrastructure ourselves**.\n```\n\n### Template 4: ADR for Deprecation\n\n```markdown\n# ADR-0020: Deprecate MongoDB in Favor of PostgreSQL\n\n## Status\n\nAccepted (Supersedes ADR-0003)\n\n## Context\n\nADR-0003 (2021) chose MongoDB for user profile storage due to schema flexibility\nneeds. Since then:\n- MongoDB's multi-document transactions remain problematic for our use case\n- Our schema has stabilized and rarely changes\n- We now have PostgreSQL expertise from other services\n- Maintaining two databases increases operational burden\n\n## Decision\n\nDeprecate MongoDB and migrate user profiles to PostgreSQL.\n\n## Migration Plan\n\n1. **Phase 1** (Week 1-2): Create PostgreSQL schema, dual-write enabled\n2. **Phase 2** (Week 3-4): Backfill historical data, validate consistency\n3. **Phase 3** (Week 5): Switch reads to PostgreSQL, monitor\n4. **Phase 4** (Week 6): Remove MongoDB writes, decommission\n\n## Consequences\n\n### Positive\n- Single database technology reduces operational complexity\n- ACID transactions for user data\n- Team can focus PostgreSQL expertise\n\n### Negative\n- Migration effort (~4 weeks)\n- Risk of data issues during migration\n- Lose some schema flexibility\n\n## Lessons Learned\n\nDocument from ADR-0003 experience:\n- Schema flexibility benefits were overestimated\n- Operational cost of multiple databases was underestimated\n- Consider long-term maintenance in technology decisions\n```\n\n### Template 5: Request for Comments (RFC) Style\n\n```markdown\n# RFC-0025: Adopt Event Sourcing for Order Management\n\n## Summary\n\nPropose adopting event sourcing pattern for the order management domain to\nimprove auditability, enable temporal queries, and support business analytics.\n\n## Motivation\n\nCurrent challenges:\n1. Audit requirements need complete order history\n2. \"What was the order state at time X?\" queries are impossible\n3. Analytics team needs event stream for real-time dashboards\n4. Order state reconstruction for customer support is manual\n\n## Detailed Design\n\n### Event Store\n\n```\nOrderCreated { orderId, customerId, items[], timestamp }\nOrderItemAdded { orderId, item, timestamp }\nOrderItemRemoved { orderId, itemId, timestamp }\nPaymentReceived { orderId, amount, paymentId, timestamp }\nOrderShipped { orderId, trackingNumber, timestamp }\n```\n\n### Projections\n\n- **CurrentOrderState**: Materialized view for queries\n- **OrderHistory**: Complete timeline for audit\n- **DailyOrderMetrics**: Analytics aggregation\n\n### Technology\n\n- Event Store: EventStoreDB (purpose-built, handles projections)\n- Alternative considered: Kafka + custom projection service\n\n## Drawbacks\n\n- Learning curve for team\n- Increased complexity vs. CRUD\n- Need to design events carefully (immutable once stored)\n- Storage growth (events never deleted)\n\n## Alternatives\n\n1. **Audit tables**: Simpler but doesn't enable temporal queries\n2. **CDC from existing DB**: Complex, doesn't change data model\n3. **Hybrid**: Event source only for order state changes\n\n## Unresolved Questions\n\n- [ ] Event schema versioning strategy\n- [ ] Retention policy for events\n- [ ] Snapshot frequency for performance\n\n## Implementation Plan\n\n1. Prototype with single order type (2 weeks)\n2. Team training on event sourcing (1 week)\n3. Full implementation and migration (4 weeks)\n4. Monitoring and optimization (ongoing)\n\n## References\n\n- [Event Sourcing by Martin Fowler](https:\u002F\u002Fmartinfowler.com\u002FeaaDev\u002FEventSourcing.html)\n- [EventStoreDB Documentation](https:\u002F\u002Fwww.eventstore.com\u002Fdocs)\n```\n\n## ADR Management\n\n### Directory Structure\n\n```\ndocs\u002F\n├── adr\u002F\n│   ├── README.md           # Index and guidelines\n│   ├── template.md         # Team's ADR template\n│   ├── 0001-use-postgresql.md\n│   ├── 0002-caching-strategy.md\n│   ├── 0003-mongodb-user-profiles.md  # [DEPRECATED]\n│   └── 0020-deprecate-mongodb.md      # Supersedes 0003\n```\n\n### ADR Index (README.md)\n\n```markdown\n# Architecture Decision Records\n\nThis directory contains Architecture Decision Records (ADRs) for [Project Name].\n\n## Index\n\n| ADR | Title | Status | Date |\n|-----|-------|--------|------|\n| 0001 | Use PostgreSQL as Primary Database | Accepted | 2024-01-10 |\n| 0002 | Caching Strategy with Redis | Accepted | 2024-01-12 |\n| 0003 | MongoDB for User Profiles | Deprecated | 2023-06-15 |\n| 0020 | Deprecate MongoDB | Accepted | 2024-01-15 |\n\n## Creating a New ADR\n\n1. Copy `template.md` to `NNNN-title-with-dashes.md`\n2. Fill in the template\n3. Submit PR for review\n4. Update this index after approval\n\n## ADR Status\n\n- **Proposed**: Under discussion\n- **Accepted**: Decision made, implementing\n- **Deprecated**: No longer relevant\n- **Superseded**: Replaced by another ADR\n- **Rejected**: Considered but not adopted\n```\n\n### Automation (adr-tools)\n\n```bash\n# Install adr-tools\nbrew install adr-tools\n\n# Initialize ADR directory\nadr init docs\u002Fadr\n\n# Create new ADR\nadr new \"Use PostgreSQL as Primary Database\"\n\n# Supersede an ADR\nadr new -s 3 \"Deprecate MongoDB in Favor of PostgreSQL\"\n\n# Generate table of contents\nadr generate toc > docs\u002Fadr\u002FREADME.md\n\n# Link related ADRs\nadr link 2 \"Complements\" 1 \"Is complemented by\"\n```\n\n## Review Process\n\n```markdown\n## ADR Review Checklist\n\n### Before Submission\n- [ ] Context clearly explains the problem\n- [ ] All viable options considered\n- [ ] Pros\u002Fcons balanced and honest\n- [ ] Consequences (positive and negative) documented\n- [ ] Related ADRs linked\n\n### During Review\n- [ ] At least 2 senior engineers reviewed\n- [ ] Affected teams consulted\n- [ ] Security implications considered\n- [ ] Cost implications documented\n- [ ] Reversibility assessed\n\n### After Acceptance\n- [ ] ADR index updated\n- [ ] Team notified\n- [ ] Implementation tickets created\n- [ ] Related documentation updated\n```\n\n## Best Practices\n\n### Do's\n- **Write ADRs early** - Before implementation starts\n- **Keep them short** - 1-2 pages maximum\n- **Be honest about trade-offs** - Include real cons\n- **Link related decisions** - Build decision graph\n- **Update status** - Deprecate when superseded\n\n### Don'ts\n- **Don't change accepted ADRs** - Write new ones to supersede\n- **Don't skip context** - Future readers need background\n- **Don't hide failures** - Rejected decisions are valuable\n- **Don't be vague** - Specific decisions, specific consequences\n- **Don't forget implementation** - ADR without action is waste\n\n## Resources\n\n- [Documenting Architecture Decisions (Michael Nygard)](https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions)\n- [MADR Template](https:\u002F\u002Fadr.github.io\u002Fmadr\u002F)\n- [ADR GitHub Organization](https:\u002F\u002Fadr.github.io\u002F)\n- [adr-tools](https:\u002F\u002Fgithub.com\u002Fnpryce\u002Fadr-tools)\n\n## Limitations\n- Use this skill only when the task clearly matches the scope described above.\n- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.\n- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.\n","","imported","https:\u002F\u002Fgithub.com\u002Fsickn33\u002Fantigravity-awesome-skills","user_system_seed","SkillOPIC",true,126,842,"2026-05-16 13:04:06",{"id":8,"name":21,"slug":22,"icon":23,"description":24,"sort":25,"createdAt":26},"编程开发","coding","mdi-code-braces","代码生成、调试、审查，提升开发效率",2,"2026-05-16 12:53:40",{"id":7,"name":28,"slug":29,"icon":30,"description":31,"moduleId":8,"sort":25,"skillCount":32,"createdAt":26},"后端开发","backend","mdi-server","API、数据库、服务端架构",296,[34],{"id":35,"skillId":4,"version":36,"fileName":37,"fileSize":38,"filePath":39,"fileHash":40,"manifest":41,"createdAt":19},"3f07d1c9-2163-4b43-b724-e6cefe8b358b","1.0.0","architecture-decision-records.zip",5525,"uploads\u002Fskills\u002Fd17c330f-cc7c-47be-9045-cd3712e4dd81\u002Farchitecture-decision-records.zip","99941f74c749eda39e8032c19ac002ed45ba25fb63e37f9a9fbca9a65b16f316","[{\"path\":\"SKILL.md\",\"isDirectory\":false,\"size\":13311}]",{"code":43,"message":44,"data":45},200,"success",{"items":46,"stats":47,"page":50},[],{"averageRating":48,"totalRatings":48,"ratingCounts":49},0,[48,48,48,48,48],{"limit":51,"offset":48,"hasMore":52,"nextOffset":51,"ratedOnly":16},15,false]