File contents Architecture Patterns
Build maintainable, testable, and scalable systems with proven architectural patterns.
Core Principles
Dependencies point inward : Business logic never depends on frameworksDependency Inversion : High-level modules don't depend on low-level modulesInterface Segregation : Many specific interfaces over one general interfaceSeparation of Concerns : Each layer has a single responsibilityTestability : Business logic testable without infrastructure
Pattern Comparison
Pattern
Core Idea
Best For
Clean Architecture
Concentric layers, deps point inward
Complex business logic
Hexagonal (Ports & Adapters)
Core + Ports + Adapters
Multiple integrations
Domain-Driven Design
Bounded contexts, rich domain
Complex domains
Layered
Horizontal layers
Simple CRUD apps
Clean Architecture (Uncle Bob)
┌─────────────────────────────────────────────────────────┐
│ Frameworks & Drivers │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Interface Adapters │ │
│ │ ┌─────────────────────────────────────────┐ │ │
│ │ │ Use Cases │ │ │
│ │ │ ┌─────────────────────────────────┐ │ │ │
│ │ │ │ Entities │ │ │ │
│ │ │ │ (Business Rules) │ │ │ │
│ │ │ └─────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
← Dependencies point inward
Layers:
Entities : Core business objects and rulesUse Cases : Application-specific business rulesInterface Adapters : Controllers, presenters, gatewaysFrameworks : Web, DB, external services
Hexagonal Architecture
┌─────────────┐
┌─────────│ REST API │──────────┐
│ └─────────────┘ │
▼ ▼
┌─────────┐ ┌─────────┐
│ Port │◄───────────────────────│ Port │
│ In │ │ Out │
└────┬────┘ └────┬────┘
│ ┌───────────┐ │
└────────►│ Domain │◄───────────┘
│ Core │
┌────────►│ │◄───────────┐
│ └───────────┘ │
┌────┴────┐ ┌────┴────┐
│ Adapter │ │ Adapter │
│ CLI │ │ DB │
└─────────┘ └─────────┘
Quick Decision Guide
Simple CRUD : Layered architectureComplex business logic : Clean ArchitectureMultiple integrations : HexagonalLarge teams, complex domain : DDD with bounded contextsMicroservices : Combine DDD + Hexagonal per service
Critical Don'ts
Never let domain depend on infrastructure
Avoid anemic domain models (data without behavior)
Don't expose ORM entities through APIs
Never put business logic in controllers
Avoid framework coupling in core logic
When to Load References
For implementation examples: Read references/implementations.md
For DDD patterns: Read references/ddd-patterns.md
External Resources
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1 --- 2 name: censseo-specforge-architecture-patterns 3 description: Architecture Patterns 4 --- 5 6 # Architecture Patterns 7 8 > Build maintainable, testable, and scalable systems with proven architectural patterns. 9 10 ## Core Principles 11 12 - **Dependencies point inward**: Business logic never depends on frameworks 13 - **Dependency Inversion**: High-level modules don't depend on low-level modules 14 - **Interface Segregation**: Many specific interfaces over one general interface 15 - **Separation of Concerns**: Each layer has a single responsibility 16 - **Testability**: Business logic testable without infrastructure 17 18 ## Pattern Comparison 19 20 | Pattern | Core Idea | Best For | 21 |---------|-----------|----------| 22 | Clean Architecture | Concentric layers, deps point inward | Complex business logic | 23 | Hexagonal (Ports & Adapters) | Core + Ports + Adapters | Multiple integrations | 24 | Domain-Driven Design | Bounded contexts, rich domain | Complex domains | 25 | Layered | Horizontal layers | Simple CRUD apps | 26 27 ## Clean Architecture (Uncle Bob) 28 29 ``` 30 ┌─────────────────────────────────────────────────────────┐ 31 │ Frameworks & Drivers │ 32 │ ┌─────────────────────────────────────────────────┐ │ 33 │ │ Interface Adapters │ │ 34 │ │ ┌─────────────────────────────────────────┐ │ │ 35 │ │ │ Use Cases │ │ │ 36 │ │ │ ┌─────────────────────────────────┐ │ │ │ 37 │ │ │ │ Entities │ │ │ │ 38 │ │ │ │ (Business Rules) │ │ │ │ 39 │ │ │ └─────────────────────────────────┘ │ │ │ 40 │ │ └─────────────────────────────────────────┘ │ │ 41 │ └─────────────────────────────────────────────────┘ │ 42 └─────────────────────────────────────────────────────────┘ 43 ← Dependencies point inward 44 ``` 45 46 **Layers:** 47 - **Entities**: Core business objects and rules 48 - **Use Cases**: Application-specific business rules 49 - **Interface Adapters**: Controllers, presenters, gateways 50 - **Frameworks**: Web, DB, external services 51 52 ## Hexagonal Architecture 53 54 ``` 55 ┌─────────────┐ 56 ┌─────────│ REST API │──────────┐ 57 │ └─────────────┘ │ 58 ▼ ▼ 59 ┌─────────┐ ┌─────────┐ 60 │ Port │◄───────────────────────│ Port │ 61 │ In │ │ Out │ 62 └────┬────┘ └────┬────┘ 63 │ ┌───────────┐ │ 64 └────────►│ Domain │◄───────────┘ 65 │ Core │ 66 ┌────────►│ │◄───────────┐ 67 │ └───────────┘ │ 68 ┌────┴────┐ ┌────┴────┐ 69 │ Adapter │ │ Adapter │ 70 │ CLI │ │ DB │ 71 └─────────┘ └─────────┘ 72 ``` 73 74 ## Quick Decision Guide 75 76 - **Simple CRUD**: Layered architecture 77 - **Complex business logic**: Clean Architecture 78 - **Multiple integrations**: Hexagonal 79 - **Large teams, complex domain**: DDD with bounded contexts 80 - **Microservices**: Combine DDD + Hexagonal per service 81 82 ## Critical Don'ts 83 84 - Never let domain depend on infrastructure 85 - Avoid anemic domain models (data without behavior) 86 - Don't expose ORM entities through APIs 87 - Never put business logic in controllers 88 - Avoid framework coupling in core logic 89 90 ## When to Load References 91 92 - For implementation examples: `Read references/implementations.md` 93 - For DDD patterns: `Read references/ddd-patterns.md` 94 95 ## External Resources 96 97 - [Clean Architecture (Uncle Bob)](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) 98 - [Hexagonal Architecture](https://alistair.cockburn.us/hexagonal-architecture/) 99 100 --- 101 > Converted and distributed by [TomeVault](https://tomevault.io/claim/censseo) — claim your Tome and manage your conversions. 102 <!-- tomevault:4.0:skill_md:2026-04-14 -->
tomevault-io/skills-registry/tree/main/censseo--specforge--architecture-patterns commit f2f8b0f21d
Frequently asked questions How do I install the Censseo Specforge Architecture Patterns skill? Run npx get-skill add tomevault-io/censseo-specforge-architecture-patterns in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
What does the Censseo Specforge Architecture Patterns skill do? Architecture Patterns It is listed under Coding & Dev Tools on SkillMD.
Is Censseo Specforge Architecture Patterns safe to use? This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
Which AI agents work with Censseo Specforge Architecture Patterns? This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Is Censseo Specforge Architecture Patterns free to use? Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
Who published Censseo Specforge Architecture Patterns? tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.
