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.

Example

The Application Stack (ABC‑C1) passes a VPC ID to a Logical Unit (ABC‑C2), which passes a subnet ID to a Resource Group (ABC‑C3).

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.

Example

A Database Resource Group returns a database endpoint to its Logical Unit, which returns it to the Application Stack.

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

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.