177 lines
5.3 KiB
Markdown
177 lines
5.3 KiB
Markdown
# Abstract Model
|
||
|
||
## Hierarchy Model
|
||
|
||
The ABC Pattern defines a strict three‑layer hierarchy of constructs (ABC‑C0):
|
||
|
||
* Application Stack (ABC‑C1) — the root deployment boundary.
|
||
* Logical Units (ABC‑C2) — first‑level domains within the application.
|
||
* Resource Groups (ABC‑C3) — fine‑grained functional clusters inside each
|
||
Logical Unit.
|
||
|
||
This hierarchy is **strictly vertical**.
|
||
|
||
Every construct belongs to exactly one parent, and no construct may exist
|
||
outside this tree.
|
||
|
||
The hierarchy expresses **encapsulation**:
|
||
|
||
* ABC‑C1 encapsulates the entire application.
|
||
* ABC‑C2 encapsulates domain‑level concerns.
|
||
* ABC‑C3 encapsulates resource‑level concerns.
|
||
|
||
Each layer exposes its behavior exclusively through its Instantiation Interface
|
||
(ABC‑C6) and its Input/Output Contracts (ABC‑C4, ABC‑C5).
|
||
|
||
## Relationship Semantics
|
||
|
||
The ABC Pattern enforces a parent–child‑only relationship model.
|
||
|
||
### Allowed relationships
|
||
|
||
A parent construct MAY instantiate children using the child’s Instantiation
|
||
Interface (ABC‑C6).
|
||
|
||
A child MAY expose outputs upward via its Output Contract (ABC‑C5).
|
||
|
||
A parent MAY route outputs from one child to another via Capturing Down
|
||
(ABC‑C7).
|
||
|
||
### Forbidden relationships
|
||
|
||
* **No lateral references:**
|
||
- Resource Groups (ABC‑C3) may not reference each other directly.
|
||
- Logical Units (ABC‑C2) may not reference each other directly.
|
||
* **No implicit dependencies:**
|
||
- A construct may not read global state, shared variables, or parent
|
||
internals.
|
||
* **No hidden communication channels:**
|
||
- All data must flow through Input/Output Contracts.
|
||
|
||
These constraints ensure loose coupling, testability, and predictable
|
||
composition.
|
||
|
||
## Interface Semantics
|
||
|
||
Every construct (ABC‑C0) defines two explicit interfaces:
|
||
|
||
### Input Contract (ABC‑C4)
|
||
|
||
The complete set of parameters required for instantiation.
|
||
A construct MUST NOT depend on any value not present in its Input Contract.
|
||
|
||
### Output Contract (ABC‑C5)
|
||
|
||
The complete set of values the construct exposes upward.
|
||
A construct MUST NOT leak internal state except through this contract.
|
||
|
||
### Interface Binding
|
||
|
||
When a parent instantiates a child:
|
||
|
||
1. The parent supplies the child’s Input Contract.
|
||
2. The child returns its Output Contract.
|
||
3. The parent may:
|
||
|
||
> * consume the outputs,
|
||
> * aggregate them,
|
||
> * or pass them down to other children.
|
||
|
||
This creates a **closed, explicit dependency graph** with no hidden edges.
|
||
|
||
## Instantiation Semantics
|
||
|
||
The Instantiation Interface (ABC‑C6) is the single mechanism through which a
|
||
construct is created.
|
||
|
||
It has three properties:
|
||
|
||
* **Stability** - The interface remains stable even if internal implementation
|
||
changes.
|
||
* **Minimality** - Only the Input Contract is accepted; no additional
|
||
parameters.
|
||
* **Purity** - Instantiation has no side effects beyond constructing the child.
|
||
|
||
Instantiation is always **top‑down**:
|
||
|
||
* ABC‑C1 instantiates ABC‑C2 constructs.
|
||
* ABC‑C2 instantiates ABC‑C3 constructs.
|
||
* No construct may instantiate its parent or siblings.
|
||
|
||
This ensures deterministic composition and predictable dependency flow.
|
||
|
||
## Data Flow Semantics
|
||
|
||
Data flows vertically through two complementary mechanisms:
|
||
|
||
### ABC‑F1 — Capturing Down (maps to ABC‑C7)
|
||
|
||
A parent passes scoped inputs to its children.
|
||
|
||
This mechanism ensures:
|
||
|
||
* Children receive only what they need.
|
||
* No child can access parent state implicitly.
|
||
* Parents mediate all cross‑domain dependencies.
|
||
|
||
### ABC‑F2 — Bubbling Up (maps to ABC‑C8)
|
||
|
||
A child exposes outputs upward to its parent.
|
||
|
||
This mechanism ensures:
|
||
|
||
* All produced values are explicit.
|
||
* Parents can aggregate or route outputs.
|
||
* No child communicates directly with siblings.
|
||
|
||
### Routing Semantics
|
||
|
||
Parents MAY:
|
||
|
||
* **Consume** outputs (e.g., store them).
|
||
* **Transform** outputs (e.g., wrap them in a composite object).
|
||
* **Re‑expose** outputs upward.
|
||
* **Pass** outputs downward to other children.
|
||
|
||
Children MAY not route data themselves.
|
||
|
||
## Conceptual Diagram
|
||
|
||
```default
|
||
Application Stack (ABC‑C1)
|
||
│
|
||
├── Logical Unit: Data (ABC‑C2)
|
||
│ ├── Resource Group: Storage (ABC‑C3)
|
||
│ └── Resource Group: Database (ABC‑C3)
|
||
│
|
||
├── Logical Unit: Logic (ABC‑C2)
|
||
│ ├── Resource Group: Compute (ABC‑C3)
|
||
│ └── Resource Group: Messaging (ABC‑C3)
|
||
│
|
||
└── Logical Unit: Presentation (ABC‑C2)
|
||
├── Resource Group: CDN (ABC‑C3)
|
||
└── Resource Group: WebApp (ABC‑C3)
|
||
```
|
||
|
||
**Downward arrows** represent Capturing Down (ABC‑F1).
|
||
|
||
**Upward arrows** represent Bubbling Up (ABC‑F2).
|
||
|
||
No horizontal arrows exist.
|
||
|
||
## Rationale & Design Intent
|
||
|
||
The ABC Pattern enforces a strict, explicit, and testable structure for cloud
|
||
infrastructure code.
|
||
|
||
* **Encapsulation** ensures each construct hides its internal details.
|
||
* **Explicit interfaces** eliminate hidden dependencies.
|
||
* **Loose coupling** prevents cross‑domain entanglement.
|
||
* **Reusability** emerges from stable Instantiation Interfaces.
|
||
* **Testability** is guaranteed because each construct can be instantiated with
|
||
mock inputs.
|
||
* **Scalability** follows naturally from the ability to evolve constructs
|
||
independently.
|
||
|
||
This model is intentionally tool‑agnostic so it can be mapped cleanly to CDK,
|
||
Terraform, Pulumi, or any imperative, as well as declarative IaC framework.
|