architecture-patterns

Name: architecture-patterns
Author: wshobson

19kinstalls4.1kforks

How to install architecture-patterns?

wshobson/agents/architecture-patterns

$npx -y skills add wshobson/agents --skill architecture-patterns

Installs into the current project.

Summary

Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design. Use this skill when designing clean architecture for a new microservice, when refactoring a monolith to use bounded contexts, when implementing hexagonal

Files · 1

View on GitHub

SKILL.md

1	# Architecture Patterns
2
3	Master proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design to build maintainable, testable, and scalable systems.
4
5	Given: a service boundary or module to architect.
6	Produces: layered structure with clear dependency rules, interface definitions, and test boundaries.
7
8	## When to Use This Skill
9
10	- Designing new backend services or microservices from scratch
11	- Refactoring monolithic applications where business logic is entangled with ORM models or HTTP concerns
12	- Establishing bounded contexts before splitting a system into services
13	- Debugging dependency cycles where infrastructure code bleeds into the domain layer
14	- Creating testable codebases where use-case tests do not require a running database
15	- Implementing domain-driven design tactical patterns (aggregates, value objects, domain events)
16
17	## Core Concepts
18
19	### 1. Clean Architecture (Uncle Bob)
20
21	Layers (dependency flows inward):
22
23	- Entities: Core business models, no framework imports
24	- Use Cases: Application business rules, orchestrate entities
25	- Interface Adapters: Controllers, presenters, gateways — translate between use cases and external formats
26	- Frameworks & Drivers: UI, database, external services — all at the outermost ring
27
28	Key Principles:
29
30	- Dependencies point inward only; inner layers know nothing about outer layers
31	- Business logic is independent of frameworks, databases, and delivery mechanisms
32	- Every layer boundary is crossed via an abstract interface
33	- Testable without UI, database, or external services
34
35	### 2. Hexagonal Architecture (Ports and Adapters)
36
37	Components:
38
39	- Domain Core: Business logic lives here, framework-free
40	- Ports: Abstract interfaces that define how the core interacts with the outside world (driving and driven)
41	- Adapters: Concrete implementations of ports (PostgreSQL adapter, Stripe adapter, REST adapter)
42
43	Benefits:
44
45	- Swap implementations without touching the core (e.g., replace PostgreSQL with DynamoDB)
46	- Use in-memory adapters in tests — no Docker required
47	- Technology decisions deferred to the edges
48
49	### 3. Domain-Driven Design (DDD)
50
51	Strategic Patterns:
52
53	- Bounded Contexts: Isolate a coherent model for one subdomain; avoid sharing a single model across the whole system
54	- Context Mapping: Define how contexts relate (Anti-Corruption Layer, Shared Kernel, Open Host Service)
55	- Ubiquitous Language: Every term in code matches the term used by domain experts
56
57	Tactical Patterns:
58
59	- Entities: Objects with stable identity that change over time
60	- Value Objects: Immutable objects identified by their attributes (Email, Money, Address)
61	- Aggregates: Consistency boundaries; only the root is accessible from outside
62	- Repositories: Persist and reconstitute aggregates; abstract over the storage mechanism
63	- Domain Events: Capture things that happened inside the domain; used for cross-aggregate coordination
64
65	## Detailed patterns and worked examples
66
67	Detailed pattern documentation lives in `references/details.md`. Read that file when the navigation tier above is insufficient.
68
69	## Testing — In-Memory Adapters
70
71	The hallmark of correctly applied Clean Architecture is that every use case can be exercised in a plain unit test with no real database, no Docker, and no network:
72
73	```python
74	# tests/unit/test_create_user.py
75	import asyncio
76	from typing import Dict, Optional
77	from domain.entities.user import User
78	from domain.interfaces.user_repository import IUserRepository
79	from use_cases.create_user import CreateUserUseCase, CreateUserRequest
80
81
82	class InMemoryUserRepository(IUserRepository):
83	def __init__(self):
84	self._store: Dict[str, User] = {}
85
86	async def find_by_id(self, user_id: str) -> Optional[User]:
87	return self._store.get(user_id)
88
89	async def find_by_email(self, email: str) -> Optional[User]:
90	return next((u for u in self._store.values() if u.email == email), None)
91
92	async def save(self, user: User) -> User:
93	self._store[user.id] = user
94	return user
95
96	async def delete(self, user_id: str) -> bool:
97	return self._store.pop(user_id, None) is not None
98
99
100	async def test_create_user_succeeds():
101	repo = InMemoryUserRepository()
102	use_case = CreateUserUseCase(user_repository=repo)
103
104	response = await use_case.execute(CreateUserRequest(email="alice@example.com", name="Alice"))
105
106	assert response.success
107	assert response.user.email == "alice@example.com"
108	assert response.user.id is not N

People who liked this also viewed

6 picks

Type

architecture-patterns

19kinstalls4.1kforks

View on GitHub

How to install architecture-patterns?

wshobson/agents/architecture-patterns

$npx -y skills add wshobson/agents --skill architecture-patterns

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Architecture Patterns
2
3	Master proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design to build maintainable, testable, and scalable systems.
4
5	Given: a service boundary or module to architect.
6	Produces: layered structure with clear dependency rules, interface definitions, and test boundaries.
7
8	## When to Use This Skill
9
10	- Designing new backend services or microservices from scratch
11	- Refactoring monolithic applications where business logic is entangled with ORM models or HTTP concerns
12	- Establishing bounded contexts before splitting a system into services
13	- Debugging dependency cycles where infrastructure code bleeds into the domain layer
14	- Creating testable codebases where use-case tests do not require a running database
15	- Implementing domain-driven design tactical patterns (aggregates, value objects, domain events)
16
17	## Core Concepts
18
19	### 1. Clean Architecture (Uncle Bob)
20
21	Layers (dependency flows inward):
22
23	- Entities: Core business models, no framework imports
24	- Use Cases: Application business rules, orchestrate entities
25	- Interface Adapters: Controllers, presenters, gateways — translate between use cases and external formats
26	- Frameworks & Drivers: UI, database, external services — all at the outermost ring
27
28	Key Principles:
29
30	- Dependencies point inward only; inner layers know nothing about outer layers
31	- Business logic is independent of frameworks, databases, and delivery mechanisms
32	- Every layer boundary is crossed via an abstract interface
33	- Testable without UI, database, or external services
34
35	### 2. Hexagonal Architecture (Ports and Adapters)
36
37	Components:
38
39	- Domain Core: Business logic lives here, framework-free
40	- Ports: Abstract interfaces that define how the core interacts with the outside world (driving and driven)
41	- Adapters: Concrete implementations of ports (PostgreSQL adapter, Stripe adapter, REST adapter)
42
43	Benefits:
44
45	- Swap implementations without touching the core (e.g., replace PostgreSQL with DynamoDB)
46	- Use in-memory adapters in tests — no Docker required
47	- Technology decisions deferred to the edges
48
49	### 3. Domain-Driven Design (DDD)
50
51	Strategic Patterns:
52
53	- Bounded Contexts: Isolate a coherent model for one subdomain; avoid sharing a single model across the whole system
54	- Context Mapping: Define how contexts relate (Anti-Corruption Layer, Shared Kernel, Open Host Service)
55	- Ubiquitous Language: Every term in code matches the term used by domain experts
56
57	Tactical Patterns:
58
59	- Entities: Objects with stable identity that change over time
60	- Value Objects: Immutable objects identified by their attributes (Email, Money, Address)
61	- Aggregates: Consistency boundaries; only the root is accessible from outside
62	- Repositories: Persist and reconstitute aggregates; abstract over the storage mechanism
63	- Domain Events: Capture things that happened inside the domain; used for cross-aggregate coordination
64
65	## Detailed patterns and worked examples
66
67	Detailed pattern documentation lives in `references/details.md`. Read that file when the navigation tier above is insufficient.
68
69	## Testing — In-Memory Adapters
70
71	The hallmark of correctly applied Clean Architecture is that every use case can be exercised in a plain unit test with no real database, no Docker, and no network:
72
73	```python
74	# tests/unit/test_create_user.py
75	import asyncio
76	from typing import Dict, Optional
77	from domain.entities.user import User
78	from domain.interfaces.user_repository import IUserRepository
79	from use_cases.create_user import CreateUserUseCase, CreateUserRequest
80
81
82	class InMemoryUserRepository(IUserRepository):
83	def __init__(self):
84	self._store: Dict[str, User] = {}
85
86	async def find_by_id(self, user_id: str) -> Optional[User]:
87	return self._store.get(user_id)
88
89	async def find_by_email(self, email: str) -> Optional[User]:
90	return next((u for u in self._store.values() if u.email == email), None)
91
92	async def save(self, user: User) -> User:
93	self._store[user.id] = user
94	return user
95
96	async def delete(self, user_id: str) -> bool:
97	return self._store.pop(user_id, None) is not None
98
99
100	async def test_create_user_succeeds():
101	repo = InMemoryUserRepository()
102	use_case = CreateUserUseCase(user_repository=repo)
103
104	response = await use_case.execute(CreateUserRequest(email="alice@example.com", name="Alice"))
105
106	assert response.success
107	assert response.user.email == "alice@example.com"
108	assert response.user.id is not N

People who liked this also viewed

6 picks

Type