|
| 1 | +<!-- |
| 2 | +SPDX-FileCopyrightText: 2025 diffo_example contributors <https://github.com/diffo-dev/diffo_example/graphs.contributors> |
| 3 | +
|
| 4 | +SPDX-License-Identifier: MIT |
| 5 | +--> |
| 6 | + |
| 7 | +# The Access Domain |
| 8 | + |
| 9 | +Access is a small **DSL service** domain — a single fictional telco delivering broadband over copper to its own customers. It models the service the telco sells (`DslAccess`) and the physical infrastructure it runs on (`Shelf`, `Card`, `Path`, `Cable`). |
| 10 | + |
| 11 | +Use it as the warm-up. The pattern is small enough to hold in your head and rich enough to show every diffo modelling primitive you'll need. NBN (the second example) revisits the same primitives with multi-tenancy and a much longer delivery chain. |
| 12 | + |
| 13 | +## What's in here |
| 14 | + |
| 15 | +| Kind | Resource | Plays the role of | |
| 16 | +|---|---|---| |
| 17 | +| Service | `DslAccess` | the broadband product the telco sells to a subscriber | |
| 18 | +| Resource | `Shelf` | a DSLAM frame at the exchange — slots for line cards | |
| 19 | +| Resource | `Card` | a line card in a shelf slot — ports for customer paths | |
| 20 | +| Resource | `Path` | the physical/logical access path from the exchange to the customer | |
| 21 | +| Resource | `Cable` | a copper cable — carries pairs assigned to paths | |
| 22 | + |
| 23 | +`Shelf`, `Card`, and `Cable` each declare a **pool**: `:slots`, `:ports`, `:pairs`. Other resources consume those pools by being assigned a value — a card takes a slot from a shelf, a path takes a port from a card and a pair from a cable. |
| 24 | + |
| 25 | +## Topology |
| 26 | + |
| 27 | +The downstream view (the assignment direction) is a stack: |
| 28 | + |
| 29 | +``` |
| 30 | +Shelf (slots pool) ─── Card (ports pool) ─── Path |
| 31 | + │ |
| 32 | + Cable (pairs pool) |
| 33 | +``` |
| 34 | + |
| 35 | +A `Card` is **assigned a slot** from its `Shelf`; a `Path` is **assigned a port** from its `Card` and **assigned pairs** from `Cable`s along the route. The consuming resource names its upstream by the role it plays — `:shelf`, `:card`, `:cable` — and that name (`alias`) sits on the assignment record so the relationship can be walked from either side. |
| 36 | + |
| 37 | +The `DslAccess` service stands in front of the resources. It's the *what we sell*; the resources are the *what makes it work*. |
| 38 | + |
| 39 | +## Inheritance — bringing upstream context up |
| 40 | + |
| 41 | +Every consumer can read characteristics from what it's part of, without copying: |
| 42 | + |
| 43 | +- `Card.shelf` brings up the **`ShelfCharacteristic`** value of the shelf this card sits in (single-hop via `:shelf`). |
| 44 | +- `Path.card` brings up the card it's plugged into (single-hop via `:card`). |
| 45 | +- `Path.shelf` brings up the shelf — two-hop via `[:card, :shelf]`. |
| 46 | +- `Shelf.cards` brings up every card sitting in a slot (reverse direction). |
| 47 | + |
| 48 | +These are derived live from the assignment graph; nothing is duplicated. |
| 49 | + |
| 50 | +## Service lifecycle |
| 51 | + |
| 52 | +`DslAccess` is a TMF service with a small state machine: |
| 53 | + |
| 54 | +``` |
| 55 | +:initial ── qualify_dsl_result ──▶ :feasibilityChecked ── design_dsl_result ──▶ :reserved |
| 56 | +``` |
| 57 | + |
| 58 | +Each transition is an Ash action. Each action shapes the JSON output — the service's `state` field reflects where you are. |
| 59 | + |
| 60 | +## Scenario walk-through |
| 61 | + |
| 62 | +The standard provisioning flow — set up the infrastructure, then qualify and design a service for a subscriber: |
| 63 | + |
| 64 | +```elixir |
| 65 | +# 1. Exchange has a shelf with a slots pool |
| 66 | +{:ok, shelf} = Access.build_shelf!(%{name: "QDONC-0001", places: [exchange]}) |
| 67 | +Access.define_shelf!(shelf, %{ |
| 68 | + characteristic_value_updates: [ |
| 69 | + shelf: [device_name: "QDONC-0001", family: :ISAM, model: "ISAM7330", technology: :DSLAM], |
| 70 | + slots: [first: 1, last: 10, assignable_type: "LineCard"] |
| 71 | + ] |
| 72 | +}) |
| 73 | + |
| 74 | +# 2. A line card consumes a slot from the shelf — it names its upstream Shelf :shelf |
| 75 | +{:ok, card} = Access.build_card!(%{name: "line card 1"}) |
| 76 | +Access.define_card!(card, %{ |
| 77 | + characteristic_value_updates: [ |
| 78 | + card: [family: :ISAM, model: "EBLT48", technology: :adsl2Plus], |
| 79 | + ports: [first: 1, last: 48, assignable_type: "ADSL2+"] |
| 80 | + ] |
| 81 | +}) |
| 82 | +Access.assign_slot!(shelf, %{ |
| 83 | + assignment: %Assignment{assignee_id: card.id, alias: :shelf, operation: :auto_assign} |
| 84 | +}) |
| 85 | + |
| 86 | +# 3. The subscriber's path through copper to the exchange |
| 87 | +{:ok, path} = Access.build_path!(%{name: "82 Rathmullen", places: [customer_site, exchange]}) |
| 88 | +Access.define_path!(path, %{ |
| 89 | + characteristic_value_updates: [path: [technology: :copper, sections: 5]] |
| 90 | +}) |
| 91 | + |
| 92 | +# 4. Cables along the route — each one assigns a pair to the path |
| 93 | +Enum.each(cables, fn cable -> |
| 94 | + Access.assign_pair!(cable, %{ |
| 95 | + assignment: %Assignment{assignee_id: path.id, alias: :cable, operation: :auto_assign} |
| 96 | + }) |
| 97 | +end) |
| 98 | + |
| 99 | +# 5. The card assigns a port to the path — the path names its upstream Card :card |
| 100 | +Access.assign_port!(card, %{ |
| 101 | + assignment: %Assignment{assignee_id: path.id, alias: :card, operation: :auto_assign} |
| 102 | +}) |
| 103 | + |
| 104 | +# 6. Now sell the service. Qualify first (do we have feasibility at this address?) |
| 105 | +{:ok, dsl} = Access.qualify_dsl(%{parties: [customer, reseller], places: [customer_site]}) |
| 106 | +{:ok, dsl} = Access.qualify_dsl_result(dsl, %{ |
| 107 | + service_operating_status: :feasible, |
| 108 | + places: [esa] |
| 109 | +}) |
| 110 | + |
| 111 | +# 7. Design — set the service's characteristics. State goes to :reserved. |
| 112 | +{:ok, dsl} = Access.design_dsl_result(dsl, %{ |
| 113 | + characteristic_value_updates: [ |
| 114 | + dslam: [device_name: "QDONC0001", model: "ISAM7330"], |
| 115 | + aggregate_interface: [interface_name: "eth0", svlan_id: 3108], |
| 116 | + circuit: [cvlan_id: 82], |
| 117 | + line: [slot: 10, port: 5] |
| 118 | + ] |
| 119 | +}) |
| 120 | +``` |
| 121 | + |
| 122 | +Read the path's brought-up context to see inheritance working live: |
| 123 | + |
| 124 | +```elixir |
| 125 | +{:ok, path} = Access.get_path_by_id(path.id, load: [:card, :shelf, :port]) |
| 126 | + |
| 127 | +path.card # ⇒ [%CardCharacteristic.Value{family: :ISAM, model: "EBLT48", ...}] |
| 128 | +path.shelf # ⇒ [%ShelfCharacteristic.Value{device_name: "QDONC-0001", ...}] (two-hop) |
| 129 | +path.port # ⇒ [1] (the port number this path was assigned) |
| 130 | +``` |
| 131 | + |
| 132 | +## Domain API reference |
| 133 | + |
| 134 | +See [_access_api.md](_access_api.md) for the auto-generated table of every `code_interface` function on `DiffoExample.Access` — function name, action, arguments, purpose. Regenerated with `mix gen.api_docs`. |
| 135 | + |
| 136 | +## What's underneath? |
| 137 | + |
| 138 | +You've been using diffo's Provider primitives the whole time — **specifications**, **typed characteristics**, **pools**, **assignments**, **relationships**, **state machines**, and the **TMF JSON encoding** that surfaces them. None of those are bespoke to Access; they all come from the [Provider domain](provider.md), which is where to look next once you've internalised this scenario. |
| 139 | + |
| 140 | +For a runnable walk-through of the scenario, open [diffo_example_access.livemd](diffo_example_access.livemd) in Livebook. |
0 commit comments