maestro-bundle 1.9.0 → 2.0.0
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/LICENSE +21 -0
- package/README.md +90 -90
- package/package.json +2 -2
- package/src/cli.mjs +75 -75
- package/templates/bundle-ai-agents/.spec/constitution.md +24 -24
- package/templates/bundle-ai-agents/AGENTS.md +71 -71
- package/templates/bundle-ai-agents/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-ai-agents-deep/.spec/constitution.md +17 -17
- package/templates/bundle-ai-agents-deep/AGENTS.md +58 -58
- package/templates/bundle-ai-agents-deep/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-ai-agents-deep/skills/deep-agent-memory/SKILL.md +158 -158
- package/templates/bundle-base/AGENTS.md +99 -99
- package/templates/bundle-data-pipeline/.spec/constitution.md +23 -23
- package/templates/bundle-data-pipeline/AGENTS.md +68 -68
- package/templates/bundle-data-pipeline/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-frontend-spa/.spec/constitution.md +21 -21
- package/templates/bundle-frontend-spa/AGENTS.md +58 -58
- package/templates/bundle-frontend-spa/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-jhipster-microservices/.spec/constitution.md +31 -31
- package/templates/bundle-jhipster-microservices/AGENTS.md +70 -70
- package/templates/bundle-jhipster-microservices/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-jhipster-monorepo/.spec/constitution.md +22 -22
- package/templates/bundle-jhipster-monorepo/AGENTS.md +64 -64
- package/templates/bundle-jhipster-monorepo/PRD_TEMPLATE.md +63 -63
|
@@ -1,50 +1,50 @@
|
|
|
1
1
|
# Product Requirements Document (PRD)
|
|
2
2
|
|
|
3
|
-
>
|
|
3
|
+
> This document defines the product requirements. It should be filled out by the requirements analyst and/or the developer before starting development. The AI agent uses this document as context to understand WHAT to build.
|
|
4
4
|
|
|
5
|
-
## 1.
|
|
5
|
+
## 1. Executive Summary
|
|
6
6
|
|
|
7
|
-
<!--
|
|
7
|
+
<!-- Describe in 2-3 sentences what the product is and what problem it solves -->
|
|
8
8
|
|
|
9
|
-
## 2.
|
|
9
|
+
## 2. Target Users
|
|
10
10
|
|
|
11
|
-
<!--
|
|
11
|
+
<!-- Who will use the system? Describe the personas -->
|
|
12
12
|
|
|
13
|
-
### Persona 1: [
|
|
14
|
-
- **
|
|
15
|
-
- **
|
|
16
|
-
- **
|
|
13
|
+
### Persona 1: [Name]
|
|
14
|
+
- **Profile:**
|
|
15
|
+
- **Goals:**
|
|
16
|
+
- **Pain points:**
|
|
17
17
|
|
|
18
|
-
## 3.
|
|
18
|
+
## 3. MVP Scope
|
|
19
19
|
|
|
20
|
-
###
|
|
20
|
+
### Included in MVP
|
|
21
21
|
- [ ] Feature 1
|
|
22
22
|
- [ ] Feature 2
|
|
23
23
|
- [ ] Feature 3
|
|
24
24
|
|
|
25
|
-
###
|
|
26
|
-
- [ ]
|
|
27
|
-
- [ ]
|
|
25
|
+
### Out of MVP (future)
|
|
26
|
+
- [ ] Future feature 1
|
|
27
|
+
- [ ] Future feature 2
|
|
28
28
|
|
|
29
29
|
## 4. User Stories
|
|
30
30
|
|
|
31
|
-
### US01: [
|
|
32
|
-
**
|
|
31
|
+
### US01: [Title]
|
|
32
|
+
**As** [persona], **I want** [action], **so that** [benefit].
|
|
33
33
|
|
|
34
|
-
**
|
|
35
|
-
- [ ]
|
|
36
|
-
- [ ]
|
|
34
|
+
**Acceptance criteria:**
|
|
35
|
+
- [ ] AC1:
|
|
36
|
+
- [ ] AC2:
|
|
37
37
|
|
|
38
|
-
### US02: [
|
|
39
|
-
**
|
|
38
|
+
### US02: [Title]
|
|
39
|
+
**As** [persona], **I want** [action], **so that** [benefit].
|
|
40
40
|
|
|
41
|
-
**
|
|
42
|
-
- [ ]
|
|
43
|
-
- [ ]
|
|
41
|
+
**Acceptance criteria:**
|
|
42
|
+
- [ ] AC1:
|
|
43
|
+
- [ ] AC2:
|
|
44
44
|
|
|
45
|
-
## 5.
|
|
45
|
+
## 5. High-Level Architecture
|
|
46
46
|
|
|
47
|
-
<!--
|
|
47
|
+
<!-- Mermaid or ASCII diagram showing the main components -->
|
|
48
48
|
|
|
49
49
|
```mermaid
|
|
50
50
|
graph LR
|
|
@@ -52,7 +52,7 @@ graph LR
|
|
|
52
52
|
B --> C[Database]
|
|
53
53
|
```
|
|
54
54
|
|
|
55
|
-
###
|
|
55
|
+
### Directory Structure
|
|
56
56
|
|
|
57
57
|
```
|
|
58
58
|
project/
|
|
@@ -61,29 +61,29 @@ project/
|
|
|
61
61
|
└── ...
|
|
62
62
|
```
|
|
63
63
|
|
|
64
|
-
## 6. Features
|
|
64
|
+
## 6. Detailed Features
|
|
65
65
|
|
|
66
|
-
### Feature 1: [
|
|
67
|
-
- **
|
|
68
|
-
- **
|
|
66
|
+
### Feature 1: [Name]
|
|
67
|
+
- **Description:**
|
|
68
|
+
- **Business rules:**
|
|
69
69
|
-
|
|
70
70
|
- **Inputs:**
|
|
71
71
|
- **Outputs:**
|
|
72
72
|
- **Edge cases:**
|
|
73
73
|
-
|
|
74
74
|
|
|
75
|
-
### Feature 2: [
|
|
76
|
-
- **
|
|
77
|
-
- **
|
|
75
|
+
### Feature 2: [Name]
|
|
76
|
+
- **Description:**
|
|
77
|
+
- **Business rules:**
|
|
78
78
|
-
|
|
79
79
|
|
|
80
|
-
## 7. Stack
|
|
80
|
+
## 7. Technology Stack
|
|
81
81
|
|
|
82
|
-
|
|
|
82
|
+
| Component | Technology | Justification |
|
|
83
83
|
|---|---|---|
|
|
84
84
|
| Backend | | |
|
|
85
85
|
| Frontend | | |
|
|
86
|
-
|
|
|
86
|
+
| Database | | |
|
|
87
87
|
| Cache | | |
|
|
88
88
|
| Deploy | | |
|
|
89
89
|
|
|
@@ -92,7 +92,7 @@ project/
|
|
|
92
92
|
### Endpoints
|
|
93
93
|
|
|
94
94
|
#### `GET /api/v1/resource`
|
|
95
|
-
- **
|
|
95
|
+
- **Description:**
|
|
96
96
|
- **Response:** `200 OK`
|
|
97
97
|
```json
|
|
98
98
|
{
|
|
@@ -104,7 +104,7 @@ project/
|
|
|
104
104
|
```
|
|
105
105
|
|
|
106
106
|
#### `POST /api/v1/resource`
|
|
107
|
-
- **
|
|
107
|
+
- **Description:**
|
|
108
108
|
- **Body:**
|
|
109
109
|
```json
|
|
110
110
|
{
|
|
@@ -113,7 +113,7 @@ project/
|
|
|
113
113
|
```
|
|
114
114
|
- **Response:** `201 Created`
|
|
115
115
|
|
|
116
|
-
## 9.
|
|
116
|
+
## 9. Data Model
|
|
117
117
|
|
|
118
118
|
```sql
|
|
119
119
|
CREATE TABLE example (
|
|
@@ -123,39 +123,39 @@ CREATE TABLE example (
|
|
|
123
123
|
);
|
|
124
124
|
```
|
|
125
125
|
|
|
126
|
-
## 10.
|
|
126
|
+
## 10. Non-Functional Requirements
|
|
127
127
|
|
|
128
|
-
|
|
|
128
|
+
| Requirement | Target | Priority |
|
|
129
129
|
|---|---|---|
|
|
130
|
-
| Performance | Response time < 500ms |
|
|
131
|
-
|
|
|
132
|
-
|
|
|
133
|
-
|
|
|
130
|
+
| Performance | Response time < 500ms | High |
|
|
131
|
+
| Availability | 99.9% uptime | Medium |
|
|
132
|
+
| Security | OWASP Top 10 | High |
|
|
133
|
+
| Scalability | Up to X simultaneous users | Medium |
|
|
134
134
|
|
|
135
|
-
## 11.
|
|
135
|
+
## 11. Implementation Phases
|
|
136
136
|
|
|
137
|
-
###
|
|
138
|
-
- [ ]
|
|
139
|
-
- [ ]
|
|
140
|
-
- [ ]
|
|
137
|
+
### Phase 1: Foundation
|
|
138
|
+
- [ ] Project setup
|
|
139
|
+
- [ ] Data model
|
|
140
|
+
- [ ] Basic endpoints
|
|
141
141
|
|
|
142
|
-
###
|
|
143
|
-
- [ ] Feature 1
|
|
144
|
-
- [ ] Feature 2
|
|
142
|
+
### Phase 2: Core Features
|
|
143
|
+
- [ ] Feature 1 complete
|
|
144
|
+
- [ ] Feature 2 complete
|
|
145
145
|
|
|
146
|
-
###
|
|
147
|
-
- [ ]
|
|
146
|
+
### Phase 3: Polish
|
|
147
|
+
- [ ] E2E tests
|
|
148
148
|
- [ ] Performance
|
|
149
|
-
- [ ]
|
|
149
|
+
- [ ] Documentation
|
|
150
150
|
|
|
151
|
-
## 12.
|
|
151
|
+
## 12. Risks and Mitigations
|
|
152
152
|
|
|
153
|
-
|
|
|
153
|
+
| Risk | Impact | Probability | Mitigation |
|
|
154
154
|
|---|---|---|---|
|
|
155
155
|
| | | | |
|
|
156
156
|
|
|
157
|
-
## 13.
|
|
157
|
+
## 13. Success Criteria
|
|
158
158
|
|
|
159
|
-
- [ ]
|
|
160
|
-
- [ ]
|
|
161
|
-
- [ ]
|
|
159
|
+
- [ ] Criterion 1
|
|
160
|
+
- [ ] Criterion 2
|
|
161
|
+
- [ ] Criterion 3
|
|
@@ -1,37 +1,37 @@
|
|
|
1
|
-
# Constitution —
|
|
1
|
+
# Constitution — JHipster Microservices Project
|
|
2
2
|
|
|
3
|
-
##
|
|
3
|
+
## Principles
|
|
4
4
|
|
|
5
|
-
1. **Spec
|
|
6
|
-
2. **Database per service** —
|
|
7
|
-
3. **
|
|
8
|
-
4. **
|
|
9
|
-
5. **
|
|
10
|
-
6. **Saga over 2PC** —
|
|
5
|
+
1. **Spec first, code later** — Every demand goes through the SDD flow before implementation
|
|
6
|
+
2. **Database per service** — Each microservice has its own database, never access another's
|
|
7
|
+
3. **Events over synchronous calls** — Prefer Kafka for communication, Feign only for queries
|
|
8
|
+
4. **Resilience mandatory** — Circuit breaker on every inter-service call
|
|
9
|
+
5. **Independent deploy** — Each service can be deployed on its own
|
|
10
|
+
6. **Saga over 2PC** — Distributed transactions via Saga pattern, never Two-Phase Commit
|
|
11
11
|
|
|
12
|
-
##
|
|
12
|
+
## Development Standards
|
|
13
13
|
|
|
14
14
|
### Java / Spring Boot
|
|
15
|
-
- Java 21+, Records
|
|
15
|
+
- Java 21+, Records for DTOs and Events
|
|
16
16
|
- Constructor injection
|
|
17
|
-
-
|
|
18
|
-
- Fallback methods
|
|
19
|
-
-
|
|
20
|
-
|
|
21
|
-
###
|
|
22
|
-
- Kafka
|
|
23
|
-
- Feign Client
|
|
24
|
-
- DTOs
|
|
25
|
-
|
|
26
|
-
###
|
|
27
|
-
- Docker Compose
|
|
28
|
-
- Kubernetes/K3s
|
|
29
|
-
- Consul
|
|
30
|
-
- Keycloak
|
|
31
|
-
|
|
32
|
-
##
|
|
33
|
-
|
|
34
|
-
- Spring Cloud Contract
|
|
35
|
-
- Testcontainers
|
|
36
|
-
- Gatling
|
|
37
|
-
- Deploy via CI/CD,
|
|
17
|
+
- Idempotency in Kafka consumers
|
|
18
|
+
- Fallback methods for circuit breakers
|
|
19
|
+
- Entities belong to ONE service
|
|
20
|
+
|
|
21
|
+
### Communication
|
|
22
|
+
- Kafka for domain events (asynchronous)
|
|
23
|
+
- Feign Client for queries (synchronous)
|
|
24
|
+
- DTOs shared by contract, never by JAR
|
|
25
|
+
|
|
26
|
+
### Infrastructure
|
|
27
|
+
- Docker Compose for dev
|
|
28
|
+
- Kubernetes/K3s for prod
|
|
29
|
+
- Consul for service discovery
|
|
30
|
+
- Keycloak for OAuth2
|
|
31
|
+
|
|
32
|
+
## Quality Standards
|
|
33
|
+
|
|
34
|
+
- Spring Cloud Contract between services
|
|
35
|
+
- Testcontainers for integration
|
|
36
|
+
- Gatling for load testing
|
|
37
|
+
- Deploy via CI/CD, never manual
|
|
@@ -1,57 +1,57 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Project: JHipster Microservices
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
You are building a microservices architecture with JHipster. Multiple Spring Boot services, centralized gateway, service discovery, asynchronous messaging, and Angular frontend.
|
|
4
4
|
|
|
5
5
|
## Specification-Driven Development (SDD)
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
**
|
|
9
|
-
|
|
7
|
+
The fundamental SDD rule is defined in the bundle-base (base AGENTS.md) and is non-negotiable:
|
|
8
|
+
**No spec, no code. No exception.** The agent must refuse to implement any demand that
|
|
9
|
+
has not gone through the `/speckit.specify` → `/speckit.plan` → `/speckit.tasks` → `/speckit.implement` flow.
|
|
10
10
|
|
|
11
|
-
|
|
12
|
-
|
|
11
|
+
If the user asks to code something without a spec, STOP and initiate the SDD flow first.
|
|
12
|
+
Check `.specify/specs/` to verify if a spec already exists for the demand.
|
|
13
13
|
|
|
14
14
|
## Product Requirements Document
|
|
15
15
|
|
|
16
|
-
|
|
16
|
+
The `PRD.md` file at the project root contains the product requirements defined by the analyst/dev. Consult it to understand WHAT to build, the user stories, acceptance criteria, data model, and API specification. This AGENTS.md defines HOW the agent should work; the PRD defines WHAT should be built.
|
|
17
17
|
|
|
18
|
-
- `PRD.md` —
|
|
18
|
+
- `PRD.md` — Product requirements, user stories, API spec, data model
|
|
19
19
|
|
|
20
20
|
## References
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
Reference documents that the agent should consult when necessary:
|
|
23
23
|
|
|
24
|
-
- `references/jhipster-microservices-guide.md` —
|
|
25
|
-
- `references/kafka-patterns.md` —
|
|
26
|
-
- `references/saga-patterns.md` — Saga pattern
|
|
27
|
-
- `references/k8s-deployment.md` —
|
|
24
|
+
- `references/jhipster-microservices-guide.md` — JHipster microservices guide
|
|
25
|
+
- `references/kafka-patterns.md` — Kafka event patterns
|
|
26
|
+
- `references/saga-patterns.md` — Saga pattern for distributed transactions
|
|
27
|
+
- `references/k8s-deployment.md` — Kubernetes deployment
|
|
28
28
|
|
|
29
|
-
## Stack
|
|
29
|
+
## Project Stack
|
|
30
30
|
|
|
31
|
-
- **Backend:** Java 21 + Spring Boot 3.x (
|
|
31
|
+
- **Backend:** Java 21 + Spring Boot 3.x (multiple JHipster services)
|
|
32
32
|
- **Gateway:** JHipster Gateway (Spring Cloud Gateway)
|
|
33
|
-
- **Service Discovery:** JHipster Registry (Eureka)
|
|
34
|
-
- **Frontend:** Angular 17+ (
|
|
35
|
-
- **
|
|
36
|
-
- **Messaging:** Apache Kafka (
|
|
37
|
-
- **Cache:** Redis (
|
|
38
|
-
- **Auth:** OAuth2 + Keycloak (
|
|
33
|
+
- **Service Discovery:** JHipster Registry (Eureka) or Consul
|
|
34
|
+
- **Frontend:** Angular 17+ (in the Gateway or separate app)
|
|
35
|
+
- **Database:** PostgreSQL (one database per service)
|
|
36
|
+
- **Messaging:** Apache Kafka (JHipster default for microservices)
|
|
37
|
+
- **Cache:** Redis (shared)
|
|
38
|
+
- **Auth:** OAuth2 + Keycloak (recommended for microservices)
|
|
39
39
|
- **Containers:** Docker Compose (dev) + Kubernetes/K3s (prod)
|
|
40
|
-
- **Migrations:** Liquibase (
|
|
40
|
+
- **Migrations:** Liquibase (per service)
|
|
41
41
|
- **CI/CD:** GitLab CI
|
|
42
42
|
- **Monitoring:** Prometheus + Grafana + ELK/Loki
|
|
43
43
|
|
|
44
|
-
##
|
|
44
|
+
## Multi-Repo or Monorepo Structure
|
|
45
45
|
|
|
46
|
-
### Monorepo (
|
|
46
|
+
### Monorepo (recommended for small teams)
|
|
47
47
|
```
|
|
48
48
|
maestro/
|
|
49
49
|
├── gateway/ # JHipster Gateway + Angular
|
|
50
50
|
│ ├── src/main/java/
|
|
51
51
|
│ ├── src/main/webapp/ # Angular app
|
|
52
52
|
│ └── pom.xml
|
|
53
|
-
├── demand-service/ #
|
|
54
|
-
│ ├── src/main/java/com/
|
|
53
|
+
├── demand-service/ # Demand microservice
|
|
54
|
+
│ ├── src/main/java/com/company/demand/
|
|
55
55
|
│ │ ├── domain/
|
|
56
56
|
│ │ ├── repository/
|
|
57
57
|
│ │ ├── service/
|
|
@@ -60,13 +60,13 @@ maestro/
|
|
|
60
60
|
│ ├── src/main/resources/
|
|
61
61
|
│ │ └── config/liquibase/
|
|
62
62
|
│ └── pom.xml
|
|
63
|
-
├── agent-service/ #
|
|
63
|
+
├── agent-service/ # Agent microservice
|
|
64
64
|
│ └── ...
|
|
65
|
-
├── tracking-service/ #
|
|
65
|
+
├── tracking-service/ # Tracking microservice
|
|
66
66
|
│ └── ...
|
|
67
|
-
├── bundle-service/ #
|
|
67
|
+
├── bundle-service/ # Bundle/skills microservice
|
|
68
68
|
│ └── ...
|
|
69
|
-
├── docker-compose/ # Docker Compose
|
|
69
|
+
├── docker-compose/ # Docker Compose for dev
|
|
70
70
|
│ ├── docker-compose.yml
|
|
71
71
|
│ ├── keycloak.yml
|
|
72
72
|
│ ├── kafka.yml
|
|
@@ -77,17 +77,17 @@ maestro/
|
|
|
77
77
|
│ ├── agent-service/
|
|
78
78
|
│ ├── gateway/
|
|
79
79
|
│ └── registry/
|
|
80
|
-
└── jhipster-jdl.jdl # JDL
|
|
80
|
+
└── jhipster-jdl.jdl # Complete JDL
|
|
81
81
|
```
|
|
82
82
|
|
|
83
|
-
## JDL
|
|
83
|
+
## JDL for Microservices
|
|
84
84
|
|
|
85
85
|
```jdl
|
|
86
86
|
application {
|
|
87
87
|
config {
|
|
88
88
|
baseName gateway
|
|
89
89
|
applicationType gateway
|
|
90
|
-
packageName com.
|
|
90
|
+
packageName com.company.gateway
|
|
91
91
|
serviceDiscoveryType consul
|
|
92
92
|
authenticationType oauth2
|
|
93
93
|
prodDatabaseType postgresql
|
|
@@ -100,7 +100,7 @@ application {
|
|
|
100
100
|
config {
|
|
101
101
|
baseName demandService
|
|
102
102
|
applicationType microservice
|
|
103
|
-
packageName com.
|
|
103
|
+
packageName com.company.demand
|
|
104
104
|
serviceDiscoveryType consul
|
|
105
105
|
authenticationType oauth2
|
|
106
106
|
prodDatabaseType postgresql
|
|
@@ -114,7 +114,7 @@ application {
|
|
|
114
114
|
config {
|
|
115
115
|
baseName agentService
|
|
116
116
|
applicationType microservice
|
|
117
|
-
packageName com.
|
|
117
|
+
packageName com.company.agent
|
|
118
118
|
serviceDiscoveryType consul
|
|
119
119
|
authenticationType oauth2
|
|
120
120
|
prodDatabaseType postgresql
|
|
@@ -128,7 +128,7 @@ application {
|
|
|
128
128
|
config {
|
|
129
129
|
baseName trackingService
|
|
130
130
|
applicationType microservice
|
|
131
|
-
packageName com.
|
|
131
|
+
packageName com.company.tracking
|
|
132
132
|
serviceDiscoveryType consul
|
|
133
133
|
authenticationType oauth2
|
|
134
134
|
prodDatabaseType postgresql
|
|
@@ -193,9 +193,9 @@ deployment {
|
|
|
193
193
|
}
|
|
194
194
|
```
|
|
195
195
|
|
|
196
|
-
##
|
|
196
|
+
## Inter-Service Communication
|
|
197
197
|
|
|
198
|
-
###
|
|
198
|
+
### Synchronous -- Feign Client (between services)
|
|
199
199
|
```java
|
|
200
200
|
@FeignClient(name = "agentService")
|
|
201
201
|
public interface AgentServiceClient {
|
|
@@ -207,9 +207,9 @@ public interface AgentServiceClient {
|
|
|
207
207
|
}
|
|
208
208
|
```
|
|
209
209
|
|
|
210
|
-
###
|
|
210
|
+
### Asynchronous -- Kafka (domain events)
|
|
211
211
|
```java
|
|
212
|
-
// Producer
|
|
212
|
+
// Producer -- demand-service
|
|
213
213
|
@Service
|
|
214
214
|
public class DemandEventProducer {
|
|
215
215
|
private final KafkaTemplate<String, DemandEvent> kafka;
|
|
@@ -222,23 +222,23 @@ public class DemandEventProducer {
|
|
|
222
222
|
}
|
|
223
223
|
}
|
|
224
224
|
|
|
225
|
-
// Consumer
|
|
225
|
+
// Consumer -- agent-service
|
|
226
226
|
@Service
|
|
227
227
|
public class DemandEventConsumer {
|
|
228
228
|
@KafkaListener(topics = "demand-events", groupId = "agent-service")
|
|
229
229
|
public void onDemandDecomposed(DemandDecomposed event) {
|
|
230
|
-
//
|
|
230
|
+
// Allocate agents for the tasks
|
|
231
231
|
taskAllocationService.allocateForDemand(event.demandId(), event.taskIds());
|
|
232
232
|
}
|
|
233
233
|
}
|
|
234
234
|
```
|
|
235
235
|
|
|
236
|
-
##
|
|
236
|
+
## Mandatory Patterns
|
|
237
237
|
|
|
238
238
|
### Database per Service
|
|
239
|
-
|
|
239
|
+
Each microservice has its own PostgreSQL database. Never access another service's database directly.
|
|
240
240
|
|
|
241
|
-
### Saga Pattern
|
|
241
|
+
### Saga Pattern for distributed transactions
|
|
242
242
|
```
|
|
243
243
|
demand-service: CreateDemand
|
|
244
244
|
→ kafka: DemandCreated
|
|
@@ -246,7 +246,7 @@ demand-service: CreateDemand
|
|
|
246
246
|
→ kafka: AgentsAllocated
|
|
247
247
|
→ demand-service: UpdateDemandStatus(PLANNED)
|
|
248
248
|
|
|
249
|
-
|
|
249
|
+
If AgentAllocation fails:
|
|
250
250
|
→ kafka: AllocationFailed
|
|
251
251
|
→ demand-service: CompensateDemand(CANCELLED)
|
|
252
252
|
```
|
|
@@ -264,47 +264,47 @@ public List<AgentDTO> fallbackGetAgents(AgentType type, Throwable t) {
|
|
|
264
264
|
}
|
|
265
265
|
```
|
|
266
266
|
|
|
267
|
-
## Docker Compose
|
|
267
|
+
## Docker Compose for dev
|
|
268
268
|
|
|
269
269
|
```bash
|
|
270
|
-
#
|
|
270
|
+
# Start everything
|
|
271
271
|
docker-compose -f docker-compose/docker-compose.yml up -d
|
|
272
272
|
|
|
273
|
-
#
|
|
273
|
+
# Start a specific service
|
|
274
274
|
docker-compose -f docker-compose/docker-compose.yml up -d demand-service
|
|
275
275
|
```
|
|
276
276
|
|
|
277
|
-
## Kubernetes
|
|
277
|
+
## Kubernetes for prod
|
|
278
278
|
|
|
279
279
|
```bash
|
|
280
280
|
# Deploy via JHipster
|
|
281
281
|
jhipster kubernetes
|
|
282
282
|
|
|
283
|
-
#
|
|
283
|
+
# Apply
|
|
284
284
|
kubectl apply -f k8s/
|
|
285
285
|
```
|
|
286
286
|
|
|
287
|
-
##
|
|
287
|
+
## Tests
|
|
288
288
|
|
|
289
|
-
- **Unit:** JUnit 5
|
|
290
|
-
- **Integration:** Testcontainers + PostgreSQL
|
|
291
|
-
- **Contract:** Spring Cloud Contract
|
|
292
|
-
- **E2E:** Cypress
|
|
293
|
-
- **Load:** Gatling (
|
|
289
|
+
- **Unit:** JUnit 5 -- entities and services (>= 90% domain)
|
|
290
|
+
- **Integration:** Testcontainers + real PostgreSQL (>= 70%)
|
|
291
|
+
- **Contract:** Spring Cloud Contract -- contracts between services
|
|
292
|
+
- **E2E:** Cypress on the gateway
|
|
293
|
+
- **Load:** Gatling (included in JHipster)
|
|
294
294
|
|
|
295
295
|
## Git
|
|
296
296
|
|
|
297
|
-
- Commits: `feat(demand-service):
|
|
298
|
-
- Branches: `feature/<service>-<
|
|
299
|
-
-
|
|
300
|
-
-
|
|
297
|
+
- Commits: `feat(demand-service): add allocation saga`
|
|
298
|
+
- Branches: `feature/<service>-<description>`
|
|
299
|
+
- One PR per service when possible
|
|
300
|
+
- Never make breaking API changes without versioning
|
|
301
301
|
|
|
302
|
-
##
|
|
302
|
+
## What NOT to do
|
|
303
303
|
|
|
304
|
-
-
|
|
305
|
-
-
|
|
306
|
-
-
|
|
307
|
-
-
|
|
308
|
-
-
|
|
309
|
-
-
|
|
310
|
-
-
|
|
304
|
+
- Do not access another service's database directly
|
|
305
|
+
- Do not make synchronous call chains (A->B->C->D) -- use events
|
|
306
|
+
- Do not share entities between services -- each has its own DTOs
|
|
307
|
+
- Do not deploy all services together -- deploy independently
|
|
308
|
+
- Do not ignore circuit breakers on inter-service calls
|
|
309
|
+
- Do not use distributed transactions (2PC) -- use Saga
|
|
310
|
+
- Do not create an "everything service" -- maintain bounded contexts
|