@eventcatalog/create-eventcatalog 4.3.8 → 4.3.9
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/dist/index.js +1 -1
- package/package.json +1 -1
- package/templates/default/domains/Catalog/index.mdx +6 -0
- package/templates/default/domains/Ordering/index.mdx +6 -0
- package/templates/default/domains/Ordering/systems/checkout-system/index.mdx +6 -0
- package/templates/default/domains/Payments/index.mdx +6 -0
- package/templates/default/domains/Payments/systems/payment-processing-system/services/PaymentAPI/index.mdx +6 -0
- package/templates/default/pages/homepage.astro +12 -2
package/dist/index.js
CHANGED
|
@@ -29831,7 +29831,7 @@ var import_os2 = __toESM(require("os"));
|
|
|
29831
29831
|
var package_default = {
|
|
29832
29832
|
name: "@eventcatalog/create-eventcatalog",
|
|
29833
29833
|
description: "Create EventCatalog with one command",
|
|
29834
|
-
version: "4.3.
|
|
29834
|
+
version: "4.3.9",
|
|
29835
29835
|
license: "MIT",
|
|
29836
29836
|
bin: {
|
|
29837
29837
|
"create-catalog": "./dist/index.js"
|
package/package.json
CHANGED
|
@@ -54,6 +54,12 @@ The **Catalog** domain is responsible for the lifecycle of every product Acme In
|
|
|
54
54
|
|
|
55
55
|
The **Product Catalog System** is the authoritative source of product data. Whenever a product is created, updated or deleted it publishes a domain event. The **Search System** subscribes to those events, keeps its search index in sync, and exposes a search API so other teams never have to query the catalog database directly.
|
|
56
56
|
|
|
57
|
+
## Architecture Graph
|
|
58
|
+
|
|
59
|
+
Where Catalog sits in the wider architecture — its systems and messages, and the neighbouring domains it talks to.
|
|
60
|
+
|
|
61
|
+
<ArchitectureGraph />
|
|
62
|
+
|
|
57
63
|
The diagram below shows the domain's systems, how they relate, and the people who interact with them.
|
|
58
64
|
|
|
59
65
|
<ContextDiagram />
|
|
@@ -68,3 +68,9 @@ The systems in this domain, how they relate, and the people who interact with th
|
|
|
68
68
|
The components that make up this domain.
|
|
69
69
|
|
|
70
70
|
<NodeGraph />
|
|
71
|
+
|
|
72
|
+
## Architecture Graph
|
|
73
|
+
|
|
74
|
+
Where Ordering sits in the wider architecture — its systems and messages, and the neighbouring domains it talks to.
|
|
75
|
+
|
|
76
|
+
<ArchitectureGraph />
|
|
@@ -55,3 +55,9 @@ The services and messages that make up this system.
|
|
|
55
55
|
- [[command\|reserve-inventory]] — reserve stock for the items in the cart.
|
|
56
56
|
- [[command\|authorize-payment]] — authorize payment for the order total.
|
|
57
57
|
- [[command\|create-order]] — create the order in the Order Management System.
|
|
58
|
+
|
|
59
|
+
## Architecture Graph
|
|
60
|
+
|
|
61
|
+
The checkout system's neighbourhood in the wider architecture.
|
|
62
|
+
|
|
63
|
+
<ArchitectureGraph />
|
|
@@ -67,3 +67,9 @@ The **Payment Processing System** is the internal orchestrator. When the Orderin
|
|
|
67
67
|
The systems in this domain, how they relate, and the people who interact with them.
|
|
68
68
|
|
|
69
69
|
<ContextDiagram />
|
|
70
|
+
|
|
71
|
+
## Architecture Graph
|
|
72
|
+
|
|
73
|
+
Where Payments sits in the wider architecture — its systems and messages, and the neighbouring domains it talks to.
|
|
74
|
+
|
|
75
|
+
<ArchitectureGraph />
|
|
@@ -46,6 +46,12 @@ The **Payment API** is the entry point to the Payment Processing System. It rece
|
|
|
46
46
|
|
|
47
47
|
<NodeGraph />
|
|
48
48
|
|
|
49
|
+
## Architecture Graph
|
|
50
|
+
|
|
51
|
+
How PaymentAPI connects to the rest of the catalog — the messages it exchanges and the systems around it.
|
|
52
|
+
|
|
53
|
+
<ArchitectureGraph />
|
|
54
|
+
|
|
49
55
|
<MessageTable format="all" limit={8} />
|
|
50
56
|
|
|
51
57
|
<Footer />
|
|
@@ -2,8 +2,8 @@
|
|
|
2
2
|
import { getCollection } from 'astro:content';
|
|
3
3
|
|
|
4
4
|
// EventCatalog injects its components via Astro.props.components. Destructure the ones
|
|
5
|
-
// this landing page uses (including the SystemContextMap
|
|
6
|
-
const { Tile, Tiles, SystemContextMap } = Astro.props.components;
|
|
5
|
+
// this landing page uses (including the ArchitectureGraph and SystemContextMap embeds).
|
|
6
|
+
const { Tile, Tiles, SystemContextMap, ArchitectureGraph } = Astro.props.components;
|
|
7
7
|
|
|
8
8
|
// Count the catalog's top-level resources. We filter out versioned/ entries so each
|
|
9
9
|
// resource is counted once (by its latest version).
|
|
@@ -49,6 +49,16 @@ const stats = [
|
|
|
49
49
|
}
|
|
50
50
|
</div>
|
|
51
51
|
|
|
52
|
+
{/* Architecture graph */}
|
|
53
|
+
<h2 class="text-2xl font-semibold text-[rgb(var(--ec-page-text))] mt-12 mb-2">Architecture</h2>
|
|
54
|
+
<p class="text-[rgb(var(--ec-page-text-muted))] font-light mb-2">
|
|
55
|
+
Every resource in the catalog and the relationships between them.
|
|
56
|
+
</p>
|
|
57
|
+
</div>
|
|
58
|
+
|
|
59
|
+
<ArchitectureGraph lens="domains" lensPicker="true" />
|
|
60
|
+
|
|
61
|
+
<div class="not-prose">
|
|
52
62
|
{/* System context map */}
|
|
53
63
|
<h2 class="text-2xl font-semibold text-[rgb(var(--ec-page-text))] mt-12 mb-2">System context map</h2>
|
|
54
64
|
<p class="text-[rgb(var(--ec-page-text-muted))] font-light mb-2">
|