菜单
Applies hexagonal (ports & adapters) architecture. Use when designing application structure, separating domain from infrastructure, creating testable boundaries, or when user mentions ports, adapters, hexagonal, or clean architecture.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Nullables — testing technique alternative to using mocking libraries. Use when writing unit tests, when code touches external I/O or state (HTTP, databases, files, clock, random) anywhere in its dependency chain, when making a system testable, or when tests are slow or flaky.
Bash script style guide. Always use when writing bash scripts, shell scripts, or CLI bash tools.
Drive a browser from the terminal with playwright-cli: snapshot the page, then act on elements by ref. Use when automating browser interactions, filling web forms, testing UIs, or driving logged-in web apps from the command line.
Facilitates deep, structured learning of a topic — gathering source material, assessing the learner's gaps, then teaching through guided Socratic sessions. Use when someone wants to genuinely study or be tutored on a subject over time, not get a quick answer.
Creates C4 architecture diagrams for designing, documenting, or understanding software architecture. Use when working through system design, mapping existing codebases, or visualizing structure at any level from system landscape down to code.
Test-driven development (TDD) process used when writing code. Use whenever you are adding any new code, unless the user explicitly asks to skip TDD or the code is exploratory/spike.
| name | hexagonal-architecture |
| description | Applies hexagonal (ports & adapters) architecture. Use when designing application structure, separating domain from infrastructure, creating testable boundaries, or when user mentions ports, adapters, hexagonal, or clean architecture. |
To decide if something belongs inside or outside the hexagon, ask:
"Does it do I/O or run out-of-process?"
Critical: Consider ALL dependencies. A component's dependencies disqualify it even if the component itself doesn't do I/O. If it depends on Spring, a database driver, or any framework—it's outside.
Common misconception: The hexagon is NOT just the domain. The hexagon contains both domain AND application layers. Adapters sit outside.
┌─────────────────────────────────────────┐
│ ADAPTERS (outside) │
│ Web, CLI, Database, External APIs │
│ ┌───────────────────────────────────┐ │
│ │ APPLICATION SERVICES │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ DOMAIN │ │ │
│ │ └─────────────────────────────┘ │ │
│ └───────────────────────────────────┘ │
└─────────────────────────────────────────┘
Dependencies flow INWARD only
Domain — Business constraints (what CAN happen). Contains Entities, Value Objects, Domain Services.
Application — Orchestration (HOW things happen). Contains Use Cases, Application Services.
Adapters — Translation to/from external world. Contains Controllers, Repositories, API clients.
Domain defines ports (interfaces). Adapters implement them.
*View or *Response → MemberView, OrderResponse*Request → CreateMemberRequest*Dbo → MemberDbostatic from(domain) → MemberView.from(member)as*() method → request.asMember()register(username, password) // Breaks when email required
Use wrapper objects that can evolve without breaking signatures.
Third-party types (GoogleUser, StripePayment) leaking into domain. Keep external types in adapters; map to domain types at the boundary.
Use cases calling other use cases creates coupling. Each use case should be self-contained, orchestrating domain objects directly.
Entities as data bags with logic scattered in services. Business rules belong IN entities and value objects.
Designing schema before domain model. Domain model comes first; database adapter maps to it.
Adapters adding logic beyond translation. Adapters should be thin—just implement the port interface.
Ports give clean seams for test doubles. Test the domain exhaustively with fast unit tests; test adapters against real infrastructure sparingly.