azcodr 1.2.1 → 1.2.2
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/.agents/skills/lets-build/references/hexagonal_bootstrap_scaffolds.md +1 -1
- package/AGENTS.md +3 -5
- package/README.md +4 -8
- package/changes.md +17 -0
- package/docs/rules/continuous_learning.md +0 -1
- package/docs/rules/design_patterns.md +52 -2
- package/docs/rules/domain_driven_design.md +25 -1
- package/memory.md +18 -1
- package/package.json +1 -1
- package/docs/knowledge/knowledge_graph.md +0 -188
- package/docs/rules/domain_expertise.md +0 -42
- package/docs/rules/gof_design_patterns_reference.md +0 -70
|
@@ -12,7 +12,7 @@ Regardless of language, all bootstrapped projects must follow this high-level se
|
|
|
12
12
|
<project-root>/
|
|
13
13
|
├── .agents/skills/ # Specialized agentic workflows (carried from azcodr template)
|
|
14
14
|
├── docs/
|
|
15
|
-
│ ├── knowledge/ #
|
|
15
|
+
│ ├── knowledge/ # Domain knowledge & living ubiquitous language glossary
|
|
16
16
|
│ └── rules/ # 41 atomic single-responsibility domain rules
|
|
17
17
|
├── specs/ # Canonical contract specifications
|
|
18
18
|
│ ├── protobuf/ # gRPC service definitions (*.proto)
|
package/AGENTS.md
CHANGED
|
@@ -59,8 +59,7 @@ To prevent context bloat and keep prompt overhead minimal, detailed engineering
|
|
|
59
59
|
| **TDD Double Loop** | [docs/rules/test_driven_development.md](./docs/rules/test_driven_development.md) | Outside-In TDD (London School), collaborator discovery, mock ownership. |
|
|
60
60
|
| **Test Coverage & Isolation** | [docs/rules/test_isolation.md](./docs/rules/test_isolation.md) | 100.00% full-stack coverage, status codes, transactional DB rollback. |
|
|
61
61
|
| **Clean Code** | [docs/rules/clean_code.md](./docs/rules/clean_code.md) | Naming, small functions, CQS, SLAP, DRY, DbC, zero side-effects. |
|
|
62
|
-
| **Design Patterns** | [docs/rules/design_patterns.md](./docs/rules/design_patterns.md) | Adapter, Factory,
|
|
63
|
-
| **GoF Design Patterns** | [docs/rules/gof_design_patterns_reference.md](./docs/rules/gof_design_patterns_reference.md) | Complete reference of all 23 GoF patterns across OOP and functional paradigms. |
|
|
62
|
+
| **Design Patterns** | [docs/rules/design_patterns.md](./docs/rules/design_patterns.md) | Adapter, Factory, Strategy, Result `<T, E>`, and complete 23 GoF catalog. |
|
|
64
63
|
| **Type Safety** | [docs/rules/typescript.md](./docs/rules/typescript.md) | Compiler strictness, branded nominal types, type safety, static sound invariants. |
|
|
65
64
|
| **ADRs** | [docs/rules/architecture_decision_records.md](./docs/rules/architecture_decision_records.md) | Authoring Lightweight Architectural Decision Records in `memory.md`. |
|
|
66
65
|
| **Authentication** | [docs/rules/authentication.md](./docs/rules/authentication.md) | In-memory access tokens, refresh token rotation (RTR), WebAuthn passkeys. |
|
|
@@ -93,12 +92,11 @@ To prevent context bloat and keep prompt overhead minimal, detailed engineering
|
|
|
93
92
|
| **React & Frontend** | [docs/rules/react.md](./docs/rules/react.md) | Modern React, shadcn/ui, TanStack Query, React Hook Form, and Zod validation. |
|
|
94
93
|
| **Requirements Engineering** | [docs/rules/requirements_engineering.md](./docs/rules/requirements_engineering.md) | User stories vs requirements, 3 C's, INVEST vertical cake slicing, Gherkin. |
|
|
95
94
|
| **Product Ownership** | [docs/rules/product_ownership.md](./docs/rules/product_ownership.md) | Product Backlog Management, OKRs, Kano/MoSCoW/RICE, Product Value, empiricism. |
|
|
96
|
-
| **Domain-Driven Design** | [docs/rules/domain_driven_design.md](./docs/rules/domain_driven_design.md) | Ubiquitous Language, Bounded Contexts,
|
|
95
|
+
| **Domain-Driven Design** | [docs/rules/domain_driven_design.md](./docs/rules/domain_driven_design.md) | Ubiquitous Language, Bounded Contexts, Aggregates, Capability Mapping. |
|
|
97
96
|
| **Workflow State Machines** | [docs/rules/workflow_state_machines.md](./docs/rules/workflow_state_machines.md) | Configurable workflows, in-aggregate invariant FSMs, transition guards & audit logs. |
|
|
98
97
|
| **Cloud-Native 12-Factor** | [docs/rules/cloud_native.md](./docs/rules/cloud_native.md) | 12-Factor (2026 Edition), OpenTelemetry (OTel), stateless isolates. |
|
|
99
98
|
| **Agentic Config & Skills** | [docs/rules/agentic_configuration.md](./docs/rules/agentic_configuration.md) | Progressive disclosure architecture, skill inquiry branches, refinement loop. |
|
|
100
99
|
| **Project Management** | [docs/rules/project_management.md](./docs/rules/project_management.md) | Work-In-Progress limits (WIP = 1), SMART developer tasks, Definition of Done. |
|
|
101
|
-
| **Domain Modeling** | [docs/rules/domain_expertise.md](./docs/rules/domain_expertise.md) | Business capabilities, Aggregate Root invariants, Ubiquitous Language. |
|
|
102
100
|
| **Relentless Questioning** | [docs/rules/relentless_questioning.md](./docs/rules/relentless_questioning.md) | Dynamic context-aware interrogation loops, adaptive decision trees. |
|
|
103
101
|
| **Workspace Isolation** | [docs/rules/workspace_isolation.md](./docs/rules/workspace_isolation.md) | Strict workspace sovereignty, zero global contamination, local ground truth. |
|
|
104
102
|
| **Continuous Learning** | [docs/rules/continuous_learning.md](./docs/rules/continuous_learning.md) | Direct rule ingestion, root-cause analysis, dynamic invariant updates. |
|
|
@@ -116,5 +114,5 @@ To prevent context bloat and keep prompt overhead minimal, detailed engineering
|
|
|
116
114
|
- [`lets-build`](.agents/skills/lets-build/SKILL.md): Conducting architecture interviews to finalize stack, frameworks, package managers, and bootstrapping projects.
|
|
117
115
|
- [`relentless-questioner`](.agents/skills/relentless-questioner/SKILL.md): Dynamic context-aware interrogation loops before planning and coding.
|
|
118
116
|
- **Relentless Skill Architecture Inquiry:** Never author or update skills on assumptions. Interrogate all 7 inquiry branches (placement, trigger intent, domain truth, gotchas/anti-patterns, determinism, progressive bloat, verification loop) defined in [docs/rules/agentic_configuration.md](./docs/rules/agentic_configuration.md) before writing `SKILL.md`.
|
|
119
|
-
- **Workspace Memory & Knowledge Hub:** Consult [`memory.md`](./memory.md) for ADRs, and [`docs/knowledge
|
|
117
|
+
- **Workspace Memory & Knowledge Hub:** Consult [`memory.md`](./memory.md) for ADRs, and [`docs/knowledge/ubiquitous_language.md`](./docs/knowledge/ubiquitous_language.md) for domain glossaries.
|
|
120
118
|
- **Harness Parity & Symlinks:** `AGENTS.md`, `CLAUDE.md`, and `agents.md` must remain identical via filesystem symbolic links to eliminate configuration divergence across different agent harnesses.
|
package/README.md
CHANGED
|
@@ -37,9 +37,8 @@
|
|
|
37
37
|
│ └── relentless-questioner/ # Context-aware dynamic interrogation loop
|
|
38
38
|
├── docs/
|
|
39
39
|
│ ├── knowledge/ # Institutional knowledge & domain contracts
|
|
40
|
-
│ │ ├── knowledge_graph.md # Visual topologies & fast-lookup matrices
|
|
41
40
|
│ │ └── ubiquitous_language.md # Living Ubiquitous Language glossary template
|
|
42
|
-
│ └── rules/ #
|
|
41
|
+
│ └── rules/ # 45 atomic single-responsibility domain rules
|
|
43
42
|
├── AGENTS.md # Lean root agentic configuration (< 120 lines)
|
|
44
43
|
├── CLAUDE.md -> AGENTS.md # Filesystem symlink for harness parity
|
|
45
44
|
├── agents.md -> AGENTS.md # Filesystem symlink for harness parity
|
|
@@ -52,15 +51,14 @@
|
|
|
52
51
|
|
|
53
52
|
## 📋 Progressive Disclosure Rules Catalog (`docs/rules/`)
|
|
54
53
|
|
|
55
|
-
The architecture enforces
|
|
54
|
+
The architecture enforces 45 atomic, single-responsibility domain rules. Read on demand to prevent prompt context bloat:
|
|
56
55
|
|
|
57
56
|
| Domain | Rule Reference File | Key Focus & Invariants |
|
|
58
57
|
|---|---|---|
|
|
59
58
|
| **TDD Double Loop** | [`test_driven_development.md`](./docs/rules/test_driven_development.md) | Uncle Bob's 3 Laws, nano-cycles, Ping-Pong pairing, outside-in double loop. |
|
|
60
59
|
| **Test Coverage & Isolation** | [`test_isolation.md`](./docs/rules/test_isolation.md) | 100.00% full-stack coverage, status codes, transactional DB rollback. |
|
|
61
60
|
| **Clean Code** | [`clean_code.md`](./docs/rules/clean_code.md) | 5 evolutionary tipping points, Refactor-Before-Add, CQS, SLAP, DRY, fitness functions. |
|
|
62
|
-
| **Design Patterns** | [`design_patterns.md`](./docs/rules/design_patterns.md) | Adapter, Factory,
|
|
63
|
-
| **GoF Design Patterns** | [`gof_design_patterns_reference.md`](./docs/rules/gof_design_patterns_reference.md) | Complete reference of all 23 GoF patterns across OOP and functional paradigms. |
|
|
61
|
+
| **Design Patterns** | [`design_patterns.md`](./docs/rules/design_patterns.md) | Adapter, Factory, Strategy, Result `<T, E>`, and complete 23 GoF catalog. |
|
|
64
62
|
| **Type Safety** | [`typescript.md`](./docs/rules/typescript.md) | Compiler strictness, branded nominal types, type safety, static sound invariants. |
|
|
65
63
|
| **ADRs** | [`architecture_decision_records.md`](./docs/rules/architecture_decision_records.md) | Authoring Lightweight Architectural Decision Records in `memory.md`. |
|
|
66
64
|
| **Authentication** | [`authentication.md`](./docs/rules/authentication.md) | In-memory access tokens, refresh token rotation (RTR), WebAuthn passkeys. |
|
|
@@ -93,12 +91,11 @@ The architecture enforces 47 atomic, single-responsibility domain rules. Read on
|
|
|
93
91
|
| **React & Frontend** | [`react.md`](./docs/rules/react.md) | Modern React, shadcn/ui, TanStack Query, React Hook Form, and Zod validation. |
|
|
94
92
|
| **Requirements Engineering** | [`requirements_engineering.md`](./docs/rules/requirements_engineering.md) | User stories vs requirements, 3 C's, INVEST vertical cake slicing, Gherkin. |
|
|
95
93
|
| **Product Ownership** | [`product_ownership.md`](./docs/rules/product_ownership.md) | Product Backlog Management, OKRs, Kano/MoSCoW/RICE, Product Value, empiricism. |
|
|
96
|
-
| **Domain-Driven Design** | [`domain_driven_design.md`](./docs/rules/domain_driven_design.md) | Problem
|
|
94
|
+
| **Domain-Driven Design** | [`domain_driven_design.md`](./docs/rules/domain_driven_design.md) | Problem vs Solution Space, Ubiquitous Language, Aggregates, Capability Mapping. |
|
|
97
95
|
| **Workflow State Machines** | [`workflow_state_machines.md`](./docs/rules/workflow_state_machines.md) | Configurable workflows, in-aggregate invariant FSMs, transition guards & audit logs. |
|
|
98
96
|
| **Cloud-Native 12-Factor** | [`cloud_native.md`](./docs/rules/cloud_native.md) | 12-Factor (2026 Edition), OpenTelemetry (OTel), stateless isolates. |
|
|
99
97
|
| **Agentic Config & Skills** | [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) | Progressive disclosure architecture, skill inquiry branches, refinement loop. |
|
|
100
98
|
| **Project Management** | [`project_management.md`](./docs/rules/project_management.md) | Work-In-Progress limits (WIP = 1), SMART developer tasks, Definition of Done. |
|
|
101
|
-
| **Domain Modeling** | [`domain_expertise.md`](./docs/rules/domain_expertise.md) | Business capabilities, Aggregate Root invariants, Ubiquitous Language. |
|
|
102
99
|
| **Relentless Questioning** | [`relentless_questioning.md`](./docs/rules/relentless_questioning.md) | Dynamic context-aware interrogation loops, adaptive decision trees. |
|
|
103
100
|
| **Workspace Isolation** | [`workspace_isolation.md`](./docs/rules/workspace_isolation.md) | Strict workspace sovereignty, zero global contamination, local ground truth. |
|
|
104
101
|
| **Continuous Learning** | [`continuous_learning.md`](./docs/rules/continuous_learning.md) | Direct 4-step rule ingestion, root-cause analysis, dynamic invariant updates. |
|
|
@@ -168,7 +165,6 @@ Once confirmed, the agent automatically executes:
|
|
|
168
165
|
|
|
169
166
|
## 🏛️ Workspace Memory & Knowledge Hub
|
|
170
167
|
|
|
171
|
-
- 🗺️ **[System Knowledge Graph](./docs/knowledge/knowledge_graph.md)**: Visual subsystem topologies and entity-relationship models.
|
|
172
168
|
- 📖 **[Living Ubiquitous Language Glossary](./docs/knowledge/ubiquitous_language.md)**: Authoritative domain vocabulary contract.
|
|
173
169
|
- 📜 **[Lightweight ADR Ledger](./memory.md)**: Formal Architectural Decision Records and governing rules.
|
|
174
170
|
- 📝 **[Upstream Changes Ledger](./changes.md)**: Record candidate improvements and generic patterns for the upstream azcodr template.
|
package/changes.md
CHANGED
|
@@ -60,3 +60,20 @@ When an AI agent or engineer discovers a generic architectural improvement, bug
|
|
|
60
60
|
4. Codified Uncle Bob's Three Laws of TDD, banned batch-test dumps, and introduced the Incremental Nano-Cycle and Ping-Pong Pair Programming protocol.
|
|
61
61
|
- **Domain Filter Verification:** Verified 100% generic; applicable across any language, stack, and project topology.
|
|
62
62
|
|
|
63
|
+
### [2026-09-25] Permanent Removal of Static Markdown Knowledge Graph
|
|
64
|
+
- **Category:** Architecture & Knowledge Hub
|
|
65
|
+
- **Target File(s):** `docs/knowledge/knowledge_graph.md`, `AGENTS.md`, `memory.md`, `README.md`, `docs/rules/continuous_learning.md`
|
|
66
|
+
- **Rationale:** Static markdown Mermaid diagrams and entity models in template repositories suffer from maintenance drift, duplicate state from code/migrations, violate Problem-First by assuming a multi-tenant web backend, and waste prompt token budget.
|
|
67
|
+
- **Description:** Permanently eliminated `docs/knowledge/knowledge_graph.md`. Enforced code, type definitions, and versioned database migrations as the single source of truth for architectural topologies. Retained `docs/knowledge/ubiquitous_language.md` for lightweight living domain vocabulary contracts.
|
|
68
|
+
- **Domain Filter Verification:** Verified 100% generic; purged of all speculative and duplicate static models.
|
|
69
|
+
|
|
70
|
+
### [2026-09-25] Workspace Rules Consolidation & Redundancy Purge
|
|
71
|
+
- **Category:** Rule & Knowledge Hub
|
|
72
|
+
- **Target File(s):** `docs/rules/domain_driven_design.md`, `docs/rules/design_patterns.md`, `docs/rules/domain_expertise.md`, `docs/rules/gof_design_patterns_reference.md`, `AGENTS.md`, `README.md`, `memory.md`
|
|
73
|
+
- **Rationale:** Eliminate duplicate and fragmented rules to optimize agent attention window, consolidate domain invariants, and uphold strict Single Responsibility across progressive disclosure documentation.
|
|
74
|
+
- **Description:**
|
|
75
|
+
1. Merged business capability mapping and Aggregate Root gatekeeper invariants from `domain_expertise.md` directly into `domain_driven_design.md`. Removed redundant `domain_expertise.md`.
|
|
76
|
+
2. Integrated the complete 23 Gang of Four patterns catalog from `gof_design_patterns_reference.md` directly into `design_patterns.md`. Removed redundant `gof_design_patterns_reference.md`.
|
|
77
|
+
3. Reduced active progressive disclosure rules from 47 to 45 while preserving 100% domain coverage.
|
|
78
|
+
- **Domain Filter Verification:** Verified 100% generic; purged of all redundant files and circular links.
|
|
79
|
+
|
|
@@ -26,5 +26,4 @@ Whenever an error, test failure, build friction, or architectural anti-pattern o
|
|
|
26
26
|
## 2. Institutional Memory Maintenance
|
|
27
27
|
|
|
28
28
|
- **Lightweight ADR Ledger**: Major technical decisions and invariant shifts are logged in [`memory.md`](../../memory.md) linking directly to the governing rule or skill.
|
|
29
|
-
- **System Knowledge Graph**: Keep [`docs/knowledge/knowledge_graph.md`](../knowledge/knowledge_graph.md) synchronized with new services, ports, or adapters to avoid repetitive token-expensive codebase discovery in future sessions.
|
|
30
29
|
- **Living Glossary**: Keep [`docs/knowledge/ubiquitous_language.md`](../knowledge/ubiquitous_language.md) updated with canonical domain terminology and forbidden synonyms.
|
|
@@ -36,6 +36,56 @@ Domain services must return explicit Result types, compelling callers to handle
|
|
|
36
36
|
|
|
37
37
|
---
|
|
38
38
|
|
|
39
|
-
## 3. GoF 23 Patterns Catalog
|
|
39
|
+
## 3. Gang of Four (GoF) 23 Patterns Master Catalog
|
|
40
40
|
|
|
41
|
-
|
|
41
|
+
### A. Creational Patterns (5 Patterns)
|
|
42
|
+
1. **Factory Method**: Define an interface for creating an object, but let subclasses or factory functions decide which class to instantiate.
|
|
43
|
+
- *Use Case:* Tenant-specific payment gateway instantiation (`StripeAdapter` vs `PayPalAdapter`).
|
|
44
|
+
2. **Abstract Factory**: Provide an interface for creating families of related or dependent objects without specifying concrete classes.
|
|
45
|
+
- *Use Case:* Multi-cloud storage factories creating matching `FileUploader`, `FileDownloader`, and `PresignedUrlGenerator` for S3, GCS, or MinIO.
|
|
46
|
+
3. **Builder**: Separate the construction of a complex object from its representation, allowing the same construction process to create different representations.
|
|
47
|
+
- *Use Case:* Fluent query builders, complex report generators, or test data builders (`OrderBuilder.withItems(...).build()`).
|
|
48
|
+
4. **Prototype**: Specify the kinds of objects to create using a prototypical instance, creating new objects by cloning this prototype.
|
|
49
|
+
- *Use Case:* Fast cloning of default tenant configuration templates without querying storage.
|
|
50
|
+
5. **Singleton (DI-Scoped)**: Ensure a class has only one instance and provide a global point of access.
|
|
51
|
+
- *Rule:* Avoid global static singletons (causes test coupling). Enforce singleton lifecycle strictly through Dependency Injection (DI) containers.
|
|
52
|
+
|
|
53
|
+
### B. Structural Patterns (7 Patterns)
|
|
54
|
+
6. **Adapter (Mandatory)**: Convert the interface of a class into another interface clients expect.
|
|
55
|
+
- *Use Case:* Wrapping 3rd-party SDKs, storage drivers, and external network clients in application-owned interfaces. *Rule: Only mock types you own.*
|
|
56
|
+
7. **Bridge**: Decouple an abstraction from its implementation so the two can vary independently.
|
|
57
|
+
- *Use Case:* Decoupling notification abstractions (`UrgentNotification`, `BatchNotification`) from delivery channels (`EmailChannel`, `SlackChannel`).
|
|
58
|
+
8. **Composite**: Compose objects into tree structures to represent part-whole hierarchies.
|
|
59
|
+
- *Use Case:* Nested RBAC permission trees or hierarchical menu navigation systems.
|
|
60
|
+
9. **Decorator**: Attach additional responsibilities to an object dynamically as a flexible alternative to subclassing.
|
|
61
|
+
- *Use Case:* Wrapping repository methods with distributed caching, OpenTelemetry tracing, or metrics logging.
|
|
62
|
+
10. **Facade**: Provide a unified, high-level interface to a complex set of interfaces in a subsystem.
|
|
63
|
+
- *Use Case:* Checkout facade orchestrating inventory verification, payment processing, invoice generation, and email notification.
|
|
64
|
+
11. **Flyweight**: Use sharing to support large numbers of fine-grained objects efficiently.
|
|
65
|
+
- *Use Case:* In-memory sharing of immutable tenant metadata and shared system role permission definitions.
|
|
66
|
+
12. **Proxy**: Provide a surrogate or placeholder for another object to control access to it.
|
|
67
|
+
- *Use Case:* Lazy-loading database relations, virtual proxies for large assets, or tenant-scoped connection proxies.
|
|
68
|
+
|
|
69
|
+
### C. Behavioral Patterns (11 Patterns)
|
|
70
|
+
13. **Chain of Responsibility**: Pass requests along a chain of handlers until a handler processes it or the chain ends.
|
|
71
|
+
- *Use Case:* Inbound gateway middleware pipelines (Authentication ➔ TenantResolution ➔ RateLimiting ➔ Controller).
|
|
72
|
+
14. **Command**: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undo.
|
|
73
|
+
- *Use Case:* Asynchronous job queues, transactional audit commands, CQRS command handlers.
|
|
74
|
+
15. **Interpreter**: Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences.
|
|
75
|
+
- *Use Case:* Custom search filter parsers (`status:active AND tier:pro`) or rule engine expression evaluation.
|
|
76
|
+
16. **Iterator**: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
|
|
77
|
+
- *Use Case:* Async iterators streaming large database cursor result sets or reading multi-part upload chunks.
|
|
78
|
+
17. **Mediator**: Define an object that encapsulates how a set of objects interact, preventing direct coupling between them.
|
|
79
|
+
- *Use Case:* In-memory event dispatcher mediating communication between decoupled domain services.
|
|
80
|
+
18. **Memento**: Without violating encapsulation, capture and externalize an object's internal state so the object can be restored to this state later.
|
|
81
|
+
- *Use Case:* Audit trail snapshots recording `before` and `after` states for rollback capabilities.
|
|
82
|
+
19. **Observer**: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.
|
|
83
|
+
- *Use Case:* Domain Event buses (`UserRegisteredEvent`, `PaymentFailedEvent`) invoking multiple listeners.
|
|
84
|
+
20. **State**: Allow an object to alter its behavior when its internal state changes, appearing as if it changed its class.
|
|
85
|
+
- *Use Case:* Subscription lifecycles (`TrialState` ➔ `ActiveState` ➔ `PastDueState` ➔ `CanceledState`) where allowed actions change dynamically.
|
|
86
|
+
21. **Strategy**: Define a family of algorithms, encapsulate each one, and make them interchangeable at runtime.
|
|
87
|
+
- *Use Case:* Dynamic fee calculation, tenant-specific password complexity policies, or feature flag evaluation providers.
|
|
88
|
+
22. **Template Method**: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.
|
|
89
|
+
- *Use Case:* Base ETL or data import pipelines with fixed steps (Extract ➔ Validate ➔ Transform ➔ Persist) where subclasses define validation.
|
|
90
|
+
23. **Visitor**: Represent an operation to be performed on the elements of an object structure, defining a new operation without changing the classes of the elements.
|
|
91
|
+
- *Use Case:* Document export engines traversing an AST of content blocks to generate HTML, Markdown, or PDF.
|
|
@@ -27,6 +27,12 @@ Software engineering fails when teams jump directly into the **Solution Space**
|
|
|
27
27
|
- **The Solution Space (The Accidents):** Concerns *how* the system is realized. Runtimes, programming languages (C, Rust, TS, Go, Java), and storage engines are **emergent outputs** derived strictly from Problem Space constraints.
|
|
28
28
|
- **The Golden Hammer Anti-Pattern:** Selecting tools (e.g., "Let's use Next.js and PostgreSQL") before mapping problem constraints forces the domain to fit the tool, creating massive accidental complexity.
|
|
29
29
|
|
|
30
|
+
### Strategic Subdomain & Capability Mapping
|
|
31
|
+
Structure enterprise business capabilities into three distinct tiers:
|
|
32
|
+
1. **Core Subdomain / Capabilities**: Proprietary value drivers and business differentiators (e.g. specialized workflow engines, dynamic pricing algorithms). Allocate 80% of architectural effort here.
|
|
33
|
+
2. **Supporting Subdomain / Capabilities**: Business functions specific to the domain but not competitive differentiators (e.g. order tracking, invoice rendering).
|
|
34
|
+
3. **Generic Subdomain / Capabilities**: Standard commoditized software (e.g. authentication, audit logging, email transport). Rely exclusively on standard open-source libraries.
|
|
35
|
+
|
|
30
36
|
---
|
|
31
37
|
|
|
32
38
|
## 2. Domain-Code Language Agreement
|
|
@@ -89,6 +95,24 @@ Acceptance criteria must be written strictly in Ubiquitous Language, serving as
|
|
|
89
95
|
|
|
90
96
|
1. **Entities**: Objects defined by identity that persists across state changes (e.g. `User`, `Order`, `Invoice`).
|
|
91
97
|
2. **Value Objects**: Immutable objects defined strictly by their attributes with no identity (e.g. `Money`, `DateRange`, `EmailAddress`).
|
|
92
|
-
3. **Aggregates & Aggregate Roots**: Clusters of domain objects treated as a single transactional consistency boundary. All mutations must pass through explicit methods on the Aggregate Root
|
|
98
|
+
3. **Aggregates & Aggregate Roots**: Clusters of domain objects treated as a single transactional consistency boundary. All mutations must pass through explicit methods on the Aggregate Root that assert invariants before committing state:
|
|
99
|
+
- **Zero Anemic Domain Models**: Domain entities must encapsulate state and validation logic. Never expose public setters that allow outside code to corrupt business rules.
|
|
100
|
+
- **Aggregate Root Gatekeeper Pattern**:
|
|
101
|
+
```typescript
|
|
102
|
+
export class OrderAggregate {
|
|
103
|
+
private constructor(private order: OrderState) {}
|
|
104
|
+
|
|
105
|
+
submit(): Result<void, DomainError> {
|
|
106
|
+
if (this.order.items.length === 0) {
|
|
107
|
+
return err(new DomainError('Cannot submit empty order'));
|
|
108
|
+
}
|
|
109
|
+
if (this.order.status !== 'DRAFT') {
|
|
110
|
+
return err(new DomainError('Order already submitted'));
|
|
111
|
+
}
|
|
112
|
+
this.order.status = 'SUBMITTED';
|
|
113
|
+
return ok(undefined);
|
|
114
|
+
}
|
|
115
|
+
}
|
|
116
|
+
```
|
|
93
117
|
4. **Anti-Corruption Layer (ACL)**: When integrating with third-party APIs or legacy systems that use different terminology, translate external payloads into the internal Ubiquitous Language at the boundary adapter before they enter the domain core.
|
|
94
118
|
5. **Cross-Aggregate Coordination in Use Cases**: While an Aggregate Root guards its own internal invariants, business operations frequently span multiple aggregates (e.g. reserving an inventory item for an agreement). Application use cases or orchestrators must coordinate aggregate transitions atomically: asserting resource availability prior to state change, transitioning the constrained entity (e.g. `ALLOCATED`), and restoring state (`AVAILABLE`) upon cancellation, avoiding double-allocation race conditions without coupling aggregates directly.
|
package/memory.md
CHANGED
|
@@ -6,7 +6,6 @@
|
|
|
6
6
|
|
|
7
7
|
## 1. Quick Navigation & Knowledge Repositories
|
|
8
8
|
|
|
9
|
-
- 🗺️ **[System Knowledge Graph](./docs/knowledge/knowledge_graph.md)**: Architectural subsystems, Mermaid topologies, entity relationships, and fast-lookup matrices.
|
|
10
9
|
- 📖 **[Living Ubiquitous Language Glossary](./docs/knowledge/ubiquitous_language.md)**: Authoritative, single-name domain vocabulary contract.
|
|
11
10
|
- 📜 **[Lightweight ADR Master Index](#adr-master-index)**: Summary of all architectural decisions and direct links to governing rules.
|
|
12
11
|
- 📝 **[Upstream Changes Ledger](./changes.md)**: Ledger of candidate improvements and generic patterns for upstream azcodr.
|
|
@@ -33,6 +32,9 @@
|
|
|
33
32
|
| **ADR-013** | Design Architecture Triage, Persistent Shell & Dev Persona Isolation | 2026-09-20 | ACCEPTED | [`ui_ux_architecture.md`](./docs/rules/ui_ux_architecture.md), [`authentication.md`](./docs/rules/authentication.md) |
|
|
34
33
|
| **ADR-014** | Product Ownership, Prioritization Models, SMART Tasks & INVEST Slicing | 2026-09-21 | ACCEPTED | [`product_ownership.md`](./docs/rules/product_ownership.md), [`requirements_engineering.md`](./docs/rules/requirements_engineering.md), [`project_management.md`](./docs/rules/project_management.md) |
|
|
35
34
|
| **ADR-015** | Problem-First Architecture, Topology Scaffolding, Tipping Points & Nano-TDD | 2026-09-25 | ACCEPTED | [`clean_code.md`](./docs/rules/clean_code.md), [`domain_driven_design.md`](./docs/rules/domain_driven_design.md), [`test_driven_development.md`](./docs/rules/test_driven_development.md), [`lets-build`](./.agents/skills/lets-build/SKILL.md) |
|
|
35
|
+
| **ADR-016** | Elimination of Static Markdown Knowledge Graph | 2026-09-25 | ACCEPTED | [`clean_code.md`](./docs/rules/clean_code.md), [`continuous_learning.md`](./docs/rules/continuous_learning.md) |
|
|
36
|
+
| **ADR-017** | Progressive Rules Consolidation (DDD & GoF Patterns) | 2026-09-25 | ACCEPTED | [`domain_driven_design.md`](./docs/rules/domain_driven_design.md), [`design_patterns.md`](./docs/rules/design_patterns.md) |
|
|
37
|
+
|
|
36
38
|
|
|
37
39
|
---
|
|
38
40
|
|
|
@@ -126,3 +128,18 @@
|
|
|
126
128
|
4. Mandate **True Incremental TDD & Nano-Cycles**: Prohibit batch-test dumps ("Test-First Waterfall"); enforce Uncle Bob's Three Laws (especially Law #2) and Ping-Pong pair programming with verified RED failure proofs.
|
|
127
129
|
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`clean_code.md`](./docs/rules/clean_code.md), [`domain_driven_design.md`](./docs/rules/domain_driven_design.md), [`test_driven_development.md`](./docs/rules/test_driven_development.md), [`lets-build`](./.agents/skills/lets-build/SKILL.md), [`architecture_interview_matrix.md`](./.agents/skills/lets-build/references/architecture_interview_matrix.md).
|
|
128
130
|
|
|
131
|
+
#### ADR-016: Elimination of Static Markdown Knowledge Graph in Favor of Code-as-Truth & Living Glossary
|
|
132
|
+
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
133
|
+
- **Context:** Template repositories often maintain static markdown files containing Mermaid diagrams, ERDs, and component topologies (`docs/knowledge/knowledge_graph.md`). In practice, these static artifacts suffer from rapid maintenance drift, violate the Problem-First mandate by pre-fabricating multi-tenant web backend models before the user defines their project, duplicate existing domain rules and memory records, and become stale tokens consumed on every context load.
|
|
134
|
+
- **Decision:** Permanently delete `docs/knowledge/knowledge_graph.md`. Treat executable code, strict type definitions, and versioned database migrations as the sole source of truth for architectural topologies. Retain `docs/knowledge/ubiquitous_language.md` as the lightweight, living domain vocabulary contract.
|
|
135
|
+
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`clean_code.md`](./docs/rules/clean_code.md), [`continuous_learning.md`](./docs/rules/continuous_learning.md), [`memory.md`](./memory.md).
|
|
136
|
+
|
|
137
|
+
#### ADR-017: Progressive Rules Consolidation (DDD & GoF Design Patterns)
|
|
138
|
+
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
139
|
+
- **Context:** Multiple domain rules exhibited redundant overlaps: `domain_expertise.md` duplicated strategic capability mapping and tactical aggregate invariants already governed by `domain_driven_design.md`, while `gof_design_patterns_reference.md` artificially fragmented design patterns into a separate satellite file from `design_patterns.md`. This fragmentation caused token bloat in `AGENTS.md` and scattered domain invariants.
|
|
140
|
+
- **Decision:**
|
|
141
|
+
1. Merge business capability tiering (Core/Supporting/Generic) and the Aggregate Root Gatekeeper invariant example into [`domain_driven_design.md`](./docs/rules/domain_driven_design.md). Delete redundant `domain_expertise.md`.
|
|
142
|
+
2. Consolidate the 23 Gang of Four patterns catalog directly into [`design_patterns.md`](./docs/rules/design_patterns.md). Delete redundant `gof_design_patterns_reference.md`.
|
|
143
|
+
3. Streamline rule catalog across `AGENTS.md` and `README.md` to 45 lean, single-responsibility, non-overlapping rules.
|
|
144
|
+
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`README.md`](./README.md), [`domain_driven_design.md`](./docs/rules/domain_driven_design.md), [`design_patterns.md`](./docs/rules/design_patterns.md).
|
|
145
|
+
|
package/package.json
CHANGED
|
@@ -1,188 +0,0 @@
|
|
|
1
|
-
# System Knowledge Graph & Architectural Topology
|
|
2
|
-
|
|
3
|
-
> **Core Purpose:** High-density, token-efficient knowledge representation of the workspace architecture, data topologies, and subsystem boundaries, eliminating repetitive discovery prompts.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Universal Hexagonal Architectural Subsystems
|
|
8
|
-
|
|
9
|
-
```mermaid
|
|
10
|
-
flowchart TD
|
|
11
|
-
subgraph Ingress["Client & Primary Ingress Adapters"]
|
|
12
|
-
UI["Multi-Platform Client (Web / Mobile / Desktop SDUI)"]
|
|
13
|
-
Gateway["Ingress Gateway / Envoy (REST / gRPC / SSE)"]
|
|
14
|
-
BrokerIn["Message Consumer (Kafka / NATS / RabbitMQ)"]
|
|
15
|
-
end
|
|
16
|
-
|
|
17
|
-
subgraph Core["Pure Invariant Domain Core (Hexagonal Ports)"]
|
|
18
|
-
direction TB
|
|
19
|
-
TenantContext["Multi-Tenant Context Resolver Port"]
|
|
20
|
-
AuthPort["Authentication & Identity Port"]
|
|
21
|
-
AuthzPort["Authorization & Policy Port"]
|
|
22
|
-
DomainServices["Domain Services & Aggregate Roots"]
|
|
23
|
-
RulePort["Dynamic Rule Engine Port (CEL / Wasm)"]
|
|
24
|
-
WorkflowPort["Workflow Orchestration Port (Temporal / BPMN)"]
|
|
25
|
-
OutboxPort["Transactional Outbox Port"]
|
|
26
|
-
CachePort["Cache & Distributed Lock Port"]
|
|
27
|
-
RepoPort["Universal Repository Port"]
|
|
28
|
-
end
|
|
29
|
-
|
|
30
|
-
subgraph Egress["Secondary / Egress Polyglot Adapters"]
|
|
31
|
-
Storage["Relational & NoSQL Storage (Postgres / MySQL / Cockroach / Mongo)"]
|
|
32
|
-
CacheStore["In-Memory Store (Redis / Valkey / Dragonfly / Memcached)"]
|
|
33
|
-
BrokerOut["Event Streaming (Kafka / NATS / RabbitMQ / CloudEvents)"]
|
|
34
|
-
AuthEngines["Policy-as-Code (OPA Rego / OpenFGA ReBAC / Cerbos)"]
|
|
35
|
-
SMTP["Transactional Email Gateway (SMTP / Providers)"]
|
|
36
|
-
end
|
|
37
|
-
|
|
38
|
-
UI --> Gateway
|
|
39
|
-
Gateway --> TenantContext
|
|
40
|
-
BrokerIn --> DomainServices
|
|
41
|
-
TenantContext --> AuthPort
|
|
42
|
-
AuthPort --> AuthzPort
|
|
43
|
-
AuthzPort --> DomainServices
|
|
44
|
-
DomainServices --> RulePort
|
|
45
|
-
DomainServices --> WorkflowPort
|
|
46
|
-
DomainServices --> OutboxPort
|
|
47
|
-
DomainServices --> CachePort
|
|
48
|
-
DomainServices --> RepoPort
|
|
49
|
-
|
|
50
|
-
RepoPort --> Storage
|
|
51
|
-
OutboxPort --> Storage
|
|
52
|
-
OutboxPort --> BrokerOut
|
|
53
|
-
CachePort --> CacheStore
|
|
54
|
-
AuthzPort --> AuthEngines
|
|
55
|
-
DomainServices --> SMTP
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
---
|
|
59
|
-
|
|
60
|
-
## 2. Multi-Tenant Data Isolation & Schema Graph
|
|
61
|
-
|
|
62
|
-
```mermaid
|
|
63
|
-
erDiagram
|
|
64
|
-
TENANT ||--o{ USER : "owns"
|
|
65
|
-
TENANT ||--o{ ROLE : "defines"
|
|
66
|
-
TENANT ||--o{ TENANT_SCHEMA : "configures"
|
|
67
|
-
TENANT ||--o{ TENANT_ENTITY : "defines"
|
|
68
|
-
TENANT_ENTITY ||--o{ TENANT_RECORD : "stores"
|
|
69
|
-
TENANT ||--o{ OUTBOX_EVENT : "emits"
|
|
70
|
-
TENANT ||--o{ AUDIT_LOG : "records"
|
|
71
|
-
|
|
72
|
-
TENANT {
|
|
73
|
-
uuid id PK
|
|
74
|
-
string slug UK
|
|
75
|
-
string name
|
|
76
|
-
string subscription_tier
|
|
77
|
-
string status
|
|
78
|
-
json theme_tokens
|
|
79
|
-
timestamptz created_at
|
|
80
|
-
}
|
|
81
|
-
|
|
82
|
-
USER {
|
|
83
|
-
uuid id PK
|
|
84
|
-
uuid tenant_id FK
|
|
85
|
-
string email UK
|
|
86
|
-
string password_hash
|
|
87
|
-
boolean mfa_enabled
|
|
88
|
-
timestamptz created_at
|
|
89
|
-
}
|
|
90
|
-
|
|
91
|
-
TENANT_SCHEMA {
|
|
92
|
-
uuid id PK
|
|
93
|
-
uuid tenant_id FK
|
|
94
|
-
string entity_name
|
|
95
|
-
json json_schema
|
|
96
|
-
int version
|
|
97
|
-
}
|
|
98
|
-
|
|
99
|
-
OUTBOX_EVENT {
|
|
100
|
-
uuid id PK
|
|
101
|
-
uuid tenant_id FK
|
|
102
|
-
string aggregate_type
|
|
103
|
-
string aggregate_id
|
|
104
|
-
string event_type
|
|
105
|
-
json payload
|
|
106
|
-
string status
|
|
107
|
-
timestamptz created_at
|
|
108
|
-
}
|
|
109
|
-
```
|
|
110
|
-
|
|
111
|
-
---
|
|
112
|
-
|
|
113
|
-
## 3. Subsystem Fast Lookup Index
|
|
114
|
-
|
|
115
|
-
| Capability | Invariant Contract / Open Standard | Swappable Polyglot Adapters | Governing Rule |
|
|
116
|
-
|---|---|---|---|
|
|
117
|
-
| **Runtime & Language** | Hexagonal Core (Zero Deps) | Polyglot (Go, Rust, Python, Java, TypeScript) | [`clean_code.md`](../rules/clean_code.md) |
|
|
118
|
-
| **Type Safety** | Sound static types & branded primitives | Rust, TypeScript, Go, Python (type hints) | [`typescript.md`](../rules/typescript.md) |
|
|
119
|
-
| **Persistence / DAL** | Abstract Repository & Unit of Work | Atlas / Flyway migrations; SQL & NoSQL drivers | [`database_transactions.md`](../rules/database_transactions.md) |
|
|
120
|
-
| **Tenant Isolation** | 4 Models (AST Interceptor, Schema, DB, Proxy) | SQL AST parser, RLS, multi-pool router, Envoy | [`multitenancy_isolation.md`](../rules/multitenancy_isolation.md) |
|
|
121
|
-
| **Dynamic Schemas** | JSON Schema Draft 2020-12 | Polyglot validators (`valico`, `gojsonschema`, `ajv`) | [`tenant_dynamic_schemas.md`](../rules/tenant_dynamic_schemas.md) |
|
|
122
|
-
| **Authentication** | OIDC, OAuth 2.1, Passkeys (WebAuthn) | PASETO, JWT with JWKS, SPIFFE/SPIRE mTLS | [`authentication.md`](../rules/authentication.md) |
|
|
123
|
-
| **Authorization** | Policy-as-Code & ReBAC | OPA (Rego/Wasm), OpenFGA (Zanzibar), Cerbos | [`authorization.md`](../rules/authorization.md) |
|
|
124
|
-
| **Pluggable Logic** | Common Expression Language (CEL) / Wasm | `cel-go`, `cel-rust`, Extism (Wasm plugins) | [`tenant_pluggable_logic.md`](../rules/tenant_pluggable_logic.md) |
|
|
125
|
-
| **Workflows** | Durable Orchestration & Statecharts | Temporal.io SDKs, Camunda/Zeebe (BPMN 2.0) | [`tenant_pluggable_logic.md`](../rules/tenant_pluggable_logic.md) |
|
|
126
|
-
| **Caching** | Abstract Cache Port with XFetch | Redis, Valkey, Dragonfly, Memcached, Local LRU | [`caching.md`](../rules/caching.md) |
|
|
127
|
-
| **Feature Flags** | OpenFeature Standard | Flipt, Unleash, LaunchDarkly, GoFeatureFlag | [`feature_flags.md`](../rules/feature_flags.md) |
|
|
128
|
-
| **Testing** | Outside-In TDD, BDD & Consumer Contracts | Cucumber/Gherkin, Pact, Schemathesis | [`test_driven_development.md`](../rules/test_driven_development.md) |
|
|
129
|
-
| **Presentation / SDUI** | Declarative JSON SDUI + DTCG Tokens | Web (React/Vue/Svelte), Mobile (Flutter/Native) | [`server_driven_ui.md`](../rules/server_driven_ui.md) |
|
|
130
|
-
| **Transactional Email** | Declarative Email Specs / MJML | SMTP Gateway, Mailpit (Local), SES/Sendgrid | [`transactional_email.md`](../rules/transactional_email.md) |
|
|
131
|
-
| **Event Streaming** | CNCF CloudEvents v1.0.2 | Kafka, NATS JetStream, RabbitMQ, SQS | [`database_transactions.md`](../rules/database_transactions.md) |
|
|
132
|
-
| **Observability** | OpenTelemetry OTLP standard | OTel Collector, Jaeger, Prometheus, OpenSearch | [`cloud_native.md`](../rules/cloud_native.md) |
|
|
133
|
-
|
|
134
|
-
---
|
|
135
|
-
|
|
136
|
-
## 4. Agentic Skill Topology & Composability Matrix
|
|
137
|
-
|
|
138
|
-
```mermaid
|
|
139
|
-
flowchart TD
|
|
140
|
-
subgraph Inputs["Inception & Intent"]
|
|
141
|
-
Req["Stakeholder Feature Request / Mutation"]
|
|
142
|
-
end
|
|
143
|
-
|
|
144
|
-
subgraph Pattern1["Pattern 1: Sequential Pipeline Chaining (Workflows)"]
|
|
145
|
-
direction TB
|
|
146
|
-
SkillRQ["relentless-questioner"]
|
|
147
|
-
SkillPA["product-analyst"]
|
|
148
|
-
SkillTDD["test_driven_development"]
|
|
149
|
-
SkillRefactor["clean-code-refactor"]
|
|
150
|
-
|
|
151
|
-
SkillRQ -->|"Feature Alignment Spec (FAS)"| SkillPA
|
|
152
|
-
SkillPA -->|"INVEST Stories & Gherkin AC"| SkillTDD
|
|
153
|
-
SkillTDD -->|"Working Green Code"| SkillRefactor
|
|
154
|
-
end
|
|
155
|
-
|
|
156
|
-
subgraph Pattern2["Pattern 2: Dynamic Skill Stacking (Contextual Composition)"]
|
|
157
|
-
AgentCore["Primary Agent Session"]
|
|
158
|
-
SkillSec["compliance-audit"]
|
|
159
|
-
SkillArch["agentic-architect"]
|
|
160
|
-
|
|
161
|
-
AgentCore -.->|"Dynamic Load"| SkillSec
|
|
162
|
-
AgentCore -.->|"Dynamic Load"| SkillArch
|
|
163
|
-
end
|
|
164
|
-
|
|
165
|
-
subgraph Pattern3["Pattern 3: Multi-Agent Subagent Delegation (Division of Labor)"]
|
|
166
|
-
Coord["Coordinator Agent"]
|
|
167
|
-
SubA["Subagent A: Compliance Auditor"]
|
|
168
|
-
SubB["Subagent B: Code Refactorer"]
|
|
169
|
-
|
|
170
|
-
Coord -->|"Invoke Task"| SubA
|
|
171
|
-
Coord -->|"Invoke Task"| SubB
|
|
172
|
-
SubA -->|"Audit Findings"| Coord
|
|
173
|
-
SubB -->|"Refactored Units"| Coord
|
|
174
|
-
end
|
|
175
|
-
|
|
176
|
-
Req --> SkillRQ
|
|
177
|
-
```
|
|
178
|
-
|
|
179
|
-
### Many-to-Many Skill Cross-Matrix
|
|
180
|
-
|
|
181
|
-
| Skill Name | Functional Specialty | Applicable Lifecycle Stages | Target Artifacts Produced |
|
|
182
|
-
|---|---|---|---|
|
|
183
|
-
| `relentless-questioner` | Context-aware ambiguity interrogation | Pre-Discovery, Pre-Planning | Feature Alignment Spec (FAS), Invariant List |
|
|
184
|
-
| `product-analyst` | Requirements decomposition & Gherkin | Phase 1: Requirements | INVEST User Stories, Gherkin Scenarios |
|
|
185
|
-
| `lets-build` | Technical infrastructure scaffolding | Initial Bootstrapping only | Package manifests, build configs, `/healthz` |
|
|
186
|
-
| `clean-code-refactor` | Code smell eradication, GoF patterns | Phase 4: TDD Inner Loop | Decoupled classes, small functions (< 30 lines) |
|
|
187
|
-
| `compliance-audit` | Security & compliance verification | Phase 1, Phase 5: DoD | Gitleaks, Semgrep, Trivy, OWASP audit logs |
|
|
188
|
-
| `agentic-architect` | Agent configuration & skill governance | Continuous meta-refinement | Atomic `SKILL.md`, `AGENTS.md`, ADR records |
|
|
@@ -1,42 +0,0 @@
|
|
|
1
|
-
# Domain Expertise, Capability Mapping & Business Invariants
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Decompose business domains into distinct capability boundaries, enforce business invariants strictly within Aggregate Roots, and protect living Ubiquitous Language.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Business Capability Mapping
|
|
8
|
-
|
|
9
|
-
Structure enterprise business logic into three distinct capability tiers:
|
|
10
|
-
1. **Core Capabilities**: Proprietary value drivers and differentiators (e.g. specialized tenant workflow engines, dynamic pricing algorithms). Allocate 80% of architectural effort here.
|
|
11
|
-
2. **Supporting Capabilities**: Business functions specific to the domain but not competitive differentiators (e.g. order tracking, invoice rendering).
|
|
12
|
-
3. **Generic Capabilities**: Standard commoditized software (e.g. authentication, audit logging, email transport). Rely exclusively on standard open-source libraries.
|
|
13
|
-
|
|
14
|
-
---
|
|
15
|
-
|
|
16
|
-
## 2. Invariant Protection within Aggregate Roots
|
|
17
|
-
|
|
18
|
-
- **Zero Anemic Domain Models**: Domain entities must encapsulate state and validation. Do not expose public setters that allow outside code to corrupt business rules.
|
|
19
|
-
- **Aggregate Root Gatekeeper**: All mutations that modify entity state or related child entities must pass through explicit methods on the Aggregate Root that assert invariants before committing state:
|
|
20
|
-
```typescript
|
|
21
|
-
export class OrderAggregate {
|
|
22
|
-
private constructor(private order: OrderState) {}
|
|
23
|
-
|
|
24
|
-
submit(): Result<void, DomainError> {
|
|
25
|
-
if (this.order.items.length === 0) {
|
|
26
|
-
return err(new DomainError('Cannot submit empty order'));
|
|
27
|
-
}
|
|
28
|
-
if (this.order.status !== 'DRAFT') {
|
|
29
|
-
return err(new DomainError('Order already submitted'));
|
|
30
|
-
}
|
|
31
|
-
this.order.status = 'SUBMITTED';
|
|
32
|
-
return ok(undefined);
|
|
33
|
-
}
|
|
34
|
-
}
|
|
35
|
-
```
|
|
36
|
-
|
|
37
|
-
---
|
|
38
|
-
|
|
39
|
-
## 3. Living Ubiquitous Language Dictionary
|
|
40
|
-
|
|
41
|
-
- Maintain strict terminology discipline across models, database tables, API schemas, and frontend labels.
|
|
42
|
-
- When domain experts or users establish a term, document it immediately and eliminate all competing synonyms across the codebase.
|
|
@@ -1,70 +0,0 @@
|
|
|
1
|
-
# Gang of Four (GoF) Design Patterns — Universal Enterprise Reference
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Master catalog of all 23 Gang of Four design patterns mapped to real-world domain architectures across OOP and functional polyglot systems.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Creational Patterns (5 Patterns)
|
|
8
|
-
|
|
9
|
-
Creational patterns abstract the instantiation process, making systems independent of how objects are created and composed.
|
|
10
|
-
|
|
11
|
-
1. **Factory Method**: Define an interface for creating an object, but let subclasses or factory functions decide which class to instantiate.
|
|
12
|
-
- *Use Case:* Tenant-specific payment gateway instantiation (`StripeAdapter` vs `PayPalAdapter`).
|
|
13
|
-
2. **Abstract Factory**: Provide an interface for creating families of related or dependent objects without specifying concrete classes.
|
|
14
|
-
- *Use Case:* Multi-cloud storage factories creating matching `FileUploader`, `FileDownloader`, and `PresignedUrlGenerator` for S3, GCS, or MinIO.
|
|
15
|
-
3. **Builder**: Separate the construction of a complex object from its representation, allowing the same construction process to create different representations.
|
|
16
|
-
- *Use Case:* Fluent query builders, complex report generators, or test data builders (`OrderBuilder.withItems(...).build()`).
|
|
17
|
-
4. **Prototype**: Specify the kinds of objects to create using a prototypical instance, creating new objects by cloning this prototype.
|
|
18
|
-
- *Use Case:* Fast cloning of default tenant configuration templates without querying storage.
|
|
19
|
-
5. **Singleton (DI-Scoped)**: Ensure a class has only one instance and provide a global point of access.
|
|
20
|
-
- *Rule:* Avoid global static singletons (causes test coupling). Enforce singleton lifecycle strictly through Dependency Injection (DI) containers.
|
|
21
|
-
|
|
22
|
-
---
|
|
23
|
-
|
|
24
|
-
## 2. Structural Patterns (7 Patterns)
|
|
25
|
-
|
|
26
|
-
Structural patterns deal with object composition and relationships, ensuring subsystems remain decoupled and flexible.
|
|
27
|
-
|
|
28
|
-
6. **Adapter (Mandatory)**: Convert the interface of a class into another interface clients expect.
|
|
29
|
-
- *Use Case:* Wrapping 3rd-party SDKs, storage drivers, and external network clients in application-owned interfaces. *Rule: Only mock types you own.*
|
|
30
|
-
7. **Bridge**: Decouple an abstraction from its implementation so the two can vary independently.
|
|
31
|
-
- *Use Case:* Decoupling notification abstractions (`UrgentNotification`, `BatchNotification`) from delivery channels (`EmailChannel`, `SlackChannel`).
|
|
32
|
-
8. **Composite**: Compose objects into tree structures to represent part-whole hierarchies.
|
|
33
|
-
- *Use Case:* Nested RBAC permission trees or hierarchical menu navigation systems.
|
|
34
|
-
9. **Decorator**: Attach additional responsibilities to an object dynamically as a flexible alternative to subclassing.
|
|
35
|
-
- *Use Case:* Wrapping repository methods with distributed caching, OpenTelemetry tracing, or metrics logging.
|
|
36
|
-
10. **Facade**: Provide a unified, high-level interface to a complex set of interfaces in a subsystem.
|
|
37
|
-
- *Use Case:* Checkout facade orchestrating inventory verification, payment processing, invoice generation, and email notification.
|
|
38
|
-
11. **Flyweight**: Use sharing to support large numbers of fine-grained objects efficiently.
|
|
39
|
-
- *Use Case:* In-memory sharing of immutable tenant metadata and shared system role permission definitions.
|
|
40
|
-
12. **Proxy**: Provide a surrogate or placeholder for another object to control access to it.
|
|
41
|
-
- *Use Case:* Lazy-loading database relations, virtual proxies for large assets, or tenant-scoped connection proxies.
|
|
42
|
-
|
|
43
|
-
---
|
|
44
|
-
|
|
45
|
-
## 3. Behavioral Patterns (11 Patterns)
|
|
46
|
-
|
|
47
|
-
Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility.
|
|
48
|
-
|
|
49
|
-
13. **Chain of Responsibility**: Pass requests along a chain of handlers until a handler processes it or the chain ends.
|
|
50
|
-
- *Use Case:* Inbound gateway middleware pipelines (Authentication ➔ TenantResolution ➔ RateLimiting ➔ Controller).
|
|
51
|
-
14. **Command**: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undo.
|
|
52
|
-
- *Use Case:* Asynchronous job queues, transactional audit commands, CQRS command handlers.
|
|
53
|
-
15. **Interpreter**: Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences.
|
|
54
|
-
- *Use Case:* Custom search filter parsers (`status:active AND tier:pro`) or rule engine expression evaluation.
|
|
55
|
-
16. **Iterator**: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
|
|
56
|
-
- *Use Case:* Async iterators streaming large database cursor result sets or reading multi-part upload chunks.
|
|
57
|
-
17. **Mediator**: Define an object that encapsulates how a set of objects interact, preventing direct coupling between them.
|
|
58
|
-
- *Use Case:* In-memory event dispatcher mediating communication between decoupled domain services.
|
|
59
|
-
18. **Memento**: Without violating encapsulation, capture and externalize an object's internal state so the object can be restored to this state later.
|
|
60
|
-
- *Use Case:* Audit trail snapshots recording `before` and `after` states for rollback capabilities.
|
|
61
|
-
19. **Observer**: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.
|
|
62
|
-
- *Use Case:* Domain Event buses (`UserRegisteredEvent`, `PaymentFailedEvent`) invoking multiple listeners.
|
|
63
|
-
20. **State**: Allow an object to alter its behavior when its internal state changes, appearing as if it changed its class.
|
|
64
|
-
- *Use Case:* Subscription lifecycles (`TrialState` ➔ `ActiveState` ➔ `PastDueState` ➔ `CanceledState`) where allowed actions change dynamically.
|
|
65
|
-
21. **Strategy**: Define a family of algorithms, encapsulate each one, and make them interchangeable at runtime.
|
|
66
|
-
- *Use Case:* Dynamic fee calculation, tenant-specific password complexity policies, or feature flag evaluation providers.
|
|
67
|
-
22. **Template Method**: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.
|
|
68
|
-
- *Use Case:* Base ETL or data import pipelines with fixed steps (Extract ➔ Validate ➔ Transform ➔ Persist) where subclasses define validation.
|
|
69
|
-
23. **Visitor**: Represent an operation to be performed on the elements of an object structure, defining a new operation without changing the classes of the elements.
|
|
70
|
-
- *Use Case:* Document export engines traversing an AST of content blocks to generate HTML, Markdown, or PDF.
|