# V4lheru Linkedin Comments Telegram Pact Architecture Patterns > Architecture Patterns Reference - Skill: `tomevault-io/v4lheru-linkedin-comments-telegram-pact-architecture-pattern` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/v4lheru-linkedin-comments-telegram-pact-architecture-pattern` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/v4lheru-linkedin-comments-telegram-pact-architecture-pattern/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/v4lheru-linkedin-comments-telegram-pact-architecture-pattern --- # Architecture Patterns Reference ## Overview This skill provides proven architectural patterns, design templates, and best practices for the PACT Architect phase. Use these patterns when designing system architecture, defining component boundaries, and creating implementation-ready specifications. ## Quick Reference: Common Patterns ### 1. Layered Architecture **When to use**: Traditional applications with clear separation of concerns **Structure**: Presentation → Business Logic → Data Access → Database **Benefits**: Clear separation, testability, familiar pattern **Trade-offs**: Can become rigid, vertical slicing challenges ### 2. Microservices Architecture **When to use**: Large-scale systems requiring independent deployment **Structure**: Independent services with well-defined APIs **Benefits**: Scalability, technology diversity, fault isolation **Trade-offs**: Operational complexity, distributed system challenges ### 3. Event-Driven Architecture **When to use**: Systems requiring loose coupling and async processing **Structure**: Event producers → Message broker → Event consumers **Benefits**: Decoupling, scalability, flexibility **Trade-offs**: Eventual consistency, debugging complexity ### 4. Hexagonal Architecture (Ports & Adapters) **When to use**: Applications requiring high testability and technology independence **Structure**: Core domain logic surrounded by adapters for external systems **Benefits**: Testability, technology agnostic, clear boundaries **Trade-offs**: More initial complexity, learning curve ### 5. CQRS (Command Query Responsibility Segregation) **When to use**: Complex domains with different read/write patterns **Structure**: Separate models and paths for commands and queries **Benefits**: Performance optimization, scaling flexibility **Trade-offs**: Increased complexity, eventual consistency challenges ## Architectural Decision Workflow For complex pattern selection and system design, use sequential-thinking to reason through decisions systematically. **When to use sequential-thinking:** - Choosing between multiple viable architectural patterns - Evaluating trade-offs for a specific context - Designing component boundaries for complex systems - Resolving conflicting requirements (e.g., performance vs. simplicity) **Workflow:** 1. **Frame the Decision** - What architectural question needs answering? - What are the constraints and requirements? - What patterns are candidates? 2. **Analyze Each Option** (use sequential-thinking) - How does each pattern address the requirements? - What are the trade-offs in this specific context? - What risks does each option introduce? 3. **Evaluate Against Principles** - Does it follow SOLID principles? - Does it avoid known anti-patterns? - Is it appropriate for the team's expertise? 4. **Document the Decision** - Record the chosen pattern and rationale - Note rejected alternatives and why - Identify risks and mitigations **Example sequential-thinking prompt:** > "I need to choose between microservices and modular monolith for a mid-size e-commerce platform with a team of 5 developers. Let me think through the trade-offs systematically..." ## Decision Tree: Which Reference to Load? **Need diagram templates?** → See `references/c4-templates.md` - Component diagrams - Container diagrams - Deployment diagrams - ASCII art examples **Designing APIs?** → See `references/api-contracts.md` - REST API patterns - GraphQL patterns - API versioning strategies - Error handling standards **Avoiding common mistakes?** → See `references/anti-patterns.md` - Big Ball of Mud - God Objects - Tight coupling issues - Over-engineering patterns ## Core Design Principles Apply these principles to all architectural decisions: 1. **Single Responsibility**: Each component has one clear purpose 2. **Open/Closed**: Design for extension without modification 3. **Dependency Inversion**: Depend on abstractions, not implementations 4. **Interface Segregation**: Many specific interfaces over one general 5. **Separation of Concerns**: Isolate different aspects of functionality 6. **Loose Coupling**: Minimize dependencies between components 7. **High Cohesion**: Related functionality grouped together ## Component Design Workflow 1. **Identify Responsibilities**: What does this component do? 2. **Define Boundaries**: What's in scope vs. out of scope? 3. **Design Interfaces**: How do other components interact? 4. **Map Data Flow**: How does information move through the system? 5. **Consider Non-Functionals**: Security, performance, scalability needs 6. **Document Decisions**: Create clear specifications for implementers ## Example: Simple REST API Architecture ``` ┌─────────────────┐ │ API Gateway │ ← Entry point, routing, rate limiting └────────┬────────┘ │ ┌────┴────┐ ▼ ▼ ┌────────┐ ┌────────┐ │ User │ │Product │ ← Domain services │Service │ │Service │ └───┬────┘ └───┬────┘ │ │ ▼ ▼ ┌──────────────────┐ │ Database │ ← Shared or separate DBs └──────────────────┘ ``` **Components**: - **API Gateway**: Request routing, authentication, rate limiting - **User Service**: User management, authentication, profiles - **Product Service**: Product catalog, inventory, search - **Database**: Data persistence (consider separate DBs per service) **For complete C4 diagram templates**: See `references/c4-templates.md` ## Technology Selection Framework When choosing technologies, consider: 1. **Team Expertise**: Does the team know this technology? 2. **Community Support**: Active development, documentation, plugins? 3. **Scalability**: Does it meet performance and scale requirements? 4. **Maintainability**: Can we maintain and debug this long-term? 5. **Cost**: Licensing, infrastructure, operational costs? 6. **Integration**: Does it work with existing systems? ## Common Architecture Patterns by Use Case **Web Applications**: - Small-Medium: Layered architecture with MVC - Large: Microservices with API gateway - Real-time: Event-driven with WebSockets **Data Processing**: - Batch: Pipeline architecture - Stream: Event-driven with message queues - Analytics: Lambda architecture (batch + stream) **Mobile Backends**: - BFF (Backend for Frontend) pattern - GraphQL for flexible queries - CDN for static content **Enterprise Systems**: - Service-oriented architecture (SOA) - Enterprise service bus (ESB) - Monorepo with shared libraries ## Interface Design Best Practices 1. **Explicit Contracts**: Document all inputs, outputs, and side effects 2. **Version Management**: Plan for API evolution from day one 3. **Error Handling**: Define standard error formats and codes 4. **Idempotency**: Design operations to be safely retryable 5. **Rate Limiting**: Protect services from overload 6. **Authentication**: Secure all interfaces appropriately ## Deployment Patterns **Single Deployment**: Simple applications, all components together **Blue-Green**: Zero-downtime deployments with instant rollback **Canary**: Gradual rollout to subset of users **Rolling**: Sequential updates across instances **Feature Flags**: Deploy code, enable features independently ## Scalability Strategies **Vertical Scaling**: Increase resources on single machine **Horizontal Scaling**: Add more machines (requires stateless design) **Caching**: Redis, CDN, application-level caching **Load Balancing**: Distribute traffic across instances **Database Sharding**: Split data across multiple databases **Read Replicas**: Separate read and write database instances ## Security Architecture Basics 1. **Defense in Depth**: Multiple layers of security 2. **Principle of Least Privilege**: Minimal permissions required 3. **Secure by Default**: Security enabled out of the box 4. **Input Validation**: Validate and sanitize all inputs 5. **Authentication & Authorization**: Who are you? What can you do? 6. **Encryption**: In transit (TLS) and at rest 7. **Audit Logging**: Track security-relevant events ## Documentation Standards Your architecture documentation should include: 1. **Context Diagram**: System boundaries and external dependencies 2. **Container Diagram**: High-level technology choices 3. **Component Diagram**: Internal structure of containers 4. **Deployment Diagram**: Infrastructure and runtime environment 5. **API Specifications**: Complete interface definitions 6. **Data Model**: Entities, relationships, and constraints 7. **Decision Log**: Why key architectural choices were made ## Additional Resources - **Comprehensive diagram templates**: `references/c4-templates.md` - **API contract examples**: `references/api-contracts.md` - **Common pitfalls to avoid**: `references/anti-patterns.md` ## Integration with PACT Workflow **Input from Prepare Phase**: - Requirements documentation - Technology research - Constraints and assumptions - Stakeholder needs **Output for Code Phase**: - Component specifications - Interface definitions - Implementation guidelines - Architecture diagrams - Technology stack decisions **Quality Gates**: - All requirements addressed - Components have clear responsibilities - Interfaces are well-defined - Non-functional requirements considered - Security built into design - Deployment strategy defined - Testing approach documented --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/v4lheru) — claim your Tome and manage your conversions.