@nt-ai-lab/opencode-skillz 0.3.13 → 0.3.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/commands/component-design.md +29 -0
- package/package.json +1 -1
|
@@ -87,6 +87,35 @@ Components should be put into the correct layer based on the type of logic they
|
|
|
87
87
|
|
|
88
88
|
- `/infra/{gateway}`: This sub-layer handles receiving inputs from the outside world and returning responses to the outside world, like gateways sitting at the edge of the application. It's common to see http controllers and event handlers in this layer. Examples of `{gateway}` include `http`, `event-handlers`. Everything inside this layer must live in a sub-folder to avoid the root becoming a dumping ground and hiding design issues.
|
|
89
89
|
|
|
90
|
+
#### Layer Import Rules
|
|
91
|
+
|
|
92
|
+
Layering is enforced by imports. The use-case layer is the orchestration layer. Use cases can depend on infra. Infra capability code must stay application-agnostic and must not depend on use cases.
|
|
93
|
+
|
|
94
|
+
Allowed dependencies:
|
|
95
|
+
|
|
96
|
+
| Dependency | Reason |
|
|
97
|
+
|---|---|
|
|
98
|
+
| `domain/**` imports `domain/**` | Domain code can use other domain concepts. |
|
|
99
|
+
| `use-case/**` imports `domain/**` | Use cases orchestrate domain behavior. |
|
|
100
|
+
| `use-case/**` imports `infra/**` | Use cases orchestrate technical capabilities and domain behavior. This includes persistence, transactions, external services, logging, queues, caches, clients, and infra-owned types. |
|
|
101
|
+
| `infra/gateway/**` imports `use-case/**` | Gateways receive outside-world input and call the use case that performs the application operation. |
|
|
102
|
+
| composition root imports `use-case/**` and `infra/**` | The composition root wires runtime dependencies. It must not contain business logic. |
|
|
103
|
+
|
|
104
|
+
Forbidden dependencies:
|
|
105
|
+
|
|
106
|
+
| Dependency | Reason |
|
|
107
|
+
|---|---|
|
|
108
|
+
| `domain/**` imports `use-case/**` | Domain rules must not know which application operations exist. |
|
|
109
|
+
| `domain/**` imports `infra/**` | Domain rules must not depend on databases, HTTP, queues, SDKs, logging, transactions, or other technical details. |
|
|
110
|
+
| `infra/persistence/**` imports `use-case/**` | Persistence is a reusable technical capability. It must not know which use cases exist. |
|
|
111
|
+
| `infra/external-service/**` imports `use-case/**` | External-service clients are reusable technical capabilities. They must not know which use cases exist. |
|
|
112
|
+
| `infra/transactions/**` imports `use-case/**` | Transaction code is a reusable technical capability. It must not know which use cases exist. |
|
|
113
|
+
| `infra/logging/**` imports `use-case/**` | Logging code is a reusable technical capability. It must not know which use cases exist. |
|
|
114
|
+
| `infra/gateway/**` imports `infra/persistence/**` directly | Gateways must not bypass use cases to load or save application state. |
|
|
115
|
+
| `infra/gateway/**` imports `infra/external-service/**` directly | Gateways must not bypass use cases to call external systems. |
|
|
116
|
+
| `infra/gateway/**` imports `domain/**` to mutate domain objects directly | Gateways must not bypass use-case orchestration. |
|
|
117
|
+
|
|
118
|
+
|
|
90
119
|
The following folder names are baned because they are generic terms that become a dumping ground or workaround for bad design. Find a more precise name or ask for help.
|
|
91
120
|
|
|
92
121
|
- `utils`
|