modern-architecture
Skill5 starsChanged 2 months agoMITView on GitHub
Design features using DDD + TDD + Clean Architecture + Event-Driven + API-First patterns for TypeScript, Python, and Go. Use when: designing features with domain complexity (Entities, Value Objects, Aggregates), structuring projects with layer separation, defining Bounded Contexts, applying Outside-In TDD, designing CQRS or Event Sourcing, creating API contracts before implementation, starting a new project architecture. Trigger phrases: DDD, TDD, clean architecture, hexagonal, ports and adapters, CQRS, event sourcing, API-first, domain model, bounded context. Do NOT use for: simple scripts, one-off utilities, UI-only components without domain logic, or CRUD-only endpoints with no business rules.
In this repository25 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adk-engineerSkill
- agent-orchestratorSkill
- brainstormingSkill
- bugfixSkill
- classify-reviewSkill
- code-reviewerSkill
- codex-reviewSkill
- context7-skillsSkill
- developer-growth-analysisSkill
- file-organizerSkill
- gcp-deploy-guardianSkill
- gws-workspaceSkill
- handoverSkill
- planSkill
- repo-cleanSkill
- review-loopSkill
- security-reviewSkill
- skill-creatorSkill
- supabase-nextjs-debuggerSkill
- tdd-workflowSkill
- test-falsifySkill
- ui-design-systemSkill
- ui-skillsSkill
- ux-researcher-designerSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 114
All domain objects return new instances.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Modern Architecture
DDD + TDD + Clean Architecture + Event-Driven + API-First for TS/Python/Go.
Decision Tree
New feature or module?
|
+- Complex business rules?
| YES -> DDD Tactical Patterns (references/ddd-tactical.md)
| |
| +- Different stakeholders use different terms for same concept?
| | YES -> Bounded Contexts (references/ddd-strategic.md)
| |
| +- External system integration?
| | YES -> Anti-Corruption Layer (references/ddd-strategic.md)
| |
| +- Read/write patterns differ significantly?
| YES -> CQRS (references/event-driven.md)
|
+- Has API surface?
| YES -> Contract-First: schema before code (references/api-first.md)
|
+- Needs async/real-time communication?
| YES -> Event-Driven (references/event-driven.md)
|
+- Any of the above?
YES -> Clean Architecture layers (references/clean-architecture.md)
NO -> Simple module, skip this skill<important if="applying Outside-In TDD with DDD or starting a new feature with domain discovery">
## Core Workflow: Outside-In Development1. Domain Discovery
Define ubiquitous language. List domain events in past tense.
Domain: Order Management
Events: OrderPlaced, OrderCancelled, PaymentReceived
Aggregates: Order, Payment, Shipment2. Contract First (if API exists)
Define API schema before writing code. See references/api-first.md.
3. Outside-In TDD
Acceptance Test (RED) -> Domain Test (RED->GREEN) -> Use Case Test (RED->GREEN) -> Adapter (GREEN) -> Acceptance (GREEN) -> RefactorFull workflow in references/tdd-ddd-workflow.md.
</important>
<important if="structuring a project with Clean Architecture layers or creating module directory layout">
### 4. Layer Implementationdomain/ -> Entities, VOs, Events, Ports (zero dependencies)
application/ -> Use Cases, Commands, Queries (depends on domain only)
infrastructure/ -> DB adapters, API controllers (depends on all)Dependency Rule: Inner layers NEVER import outer layers.
Directory Structure
src/modules/{context-name}/
domain/
model/ # Aggregate Root, Entities, Value Objects
events/ # Domain Events (past tense)
ports/ # Repository & Service interfaces
services/ # Domain Services (stateless)
application/
use-cases/ # One class per use case
dto/ # Commands & Queries
infrastructure/
persistence/ # Repository implementations + Mappers
api/ # HTTP Controllers / GraphQL Resolvers
messaging/ # Event publishers / subscribers</important><important if="naming DDD entities, value objects, events, repositories, or commands">
## Naming Conventions| Concept | Pattern | Example |
| Entity | Domain noun | Order, Customer |
| Value Object | Immutable concept | Money, Address, Email |
| Domain Event | Past tense | OrderPlaced, PaymentReceived |
| Use Case | Verb phrase | PlaceOrder, CancelOrder |
| Repository | {Aggregate}Repository | OrderRepository |
| Port | Interface in domain | PaymentGateway |
| Adapter | {Tech}{Port} | StripePaymentGateway |
| Command | {Action}{Noun}Command | PlaceOrderCommand |
| Query | Get{Noun}Query | GetOrderQuery |
</important><important if="implementing domain objects or reviewing domain model mutations">
## Immutability RuleAll domain objects return new instances. Never mutate.
// CORRECT: return new instance
addItem(item: OrderItem): Order {
return new Order(this.id, [...this._items, item], this._status)
}
// WRONG: mutation
addItem(item: OrderItem): void {
this._items.push(item) // VIOLATION
}</important><important if="planning test strategy for a Clean Architecture project">
## Test Pyramid| Layer | Type | Dependencies | Target |
| Domain | Unit | None (pure) | less than 1ms |
| Application | Unit | Mocked ports | less than 10ms |
| Infrastructure | Integration | Real DB | less than 500ms |
| E2E | Acceptance | Full stack | less than 3s |
</important><important if="deciding whether to apply DDD or assessing over-engineering risk">
## Error Handling| Situation | Action |
| Domain complexity unclear | Start with simple module; extract domain layer when rules emerge |
| Bounded Context boundaries uncertain | Map team/stakeholder language first; split where language diverges |
| Existing codebase has no layers | Introduce layers incrementally; start with domain extraction |
| Over-engineering risk | If entity has no business rules, use plain DTO -- skip DDD |
</important>References
references/ddd-tactical.md-- Entity, VO, Aggregate, Repository, Domain Event, Factory (TS/Python/Go)references/ddd-strategic.md-- Bounded Context, Context Map, Anti-Corruption Layerreferences/clean-architecture.md-- Layers, Ports and Adapters, DI, testing per layerreferences/event-driven.md-- Event Bus, CQRS, Event Sourcing, Pub/Subreferences/api-first.md-- OpenAPI, tRPC, GraphQL, versioning, error contractsreferences/tdd-ddd-workflow.md-- Outside-In TDD phases, property-based testing
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

