architecture: dependency resolution (mechanics for the dependency-modeling patterns) - #47
Merged
Merged
Conversation
How DCM merges the authored UDLM estate + discovered/derived/provider/policy dependencies into one effective dependency graph that consumers (ordered shutdown/startup, visualizers, impact analysis) run on. Documents the insertion mechanisms, the build-time resolution pass (bundle expansion, scope derivation, transitive chains, cycle detection), and best-practice guidance on choosing an authoring pattern/granularity. Pairs with UDLM docs/dependency-modeling.md (the data-model side). Co-Authored-By: Chris Roadfeldt <chris@roadfeldt.com>
… example) Worked example showing the resolution pass collapse four authoring patterns (component-chain power, realm bundle, direct edge, location) into one effective graph + derived shutdown order: bundle expansion adds 8 derived edges, PSU->feed chains give host-a the union of both rails, control-plane identity/DNS sort last. Pairs with architecture/dependency-resolution.md + UDLM examples/dependency-modeling. Co-Authored-By: Chris Roadfeldt <chris@roadfeldt.com>
Bundling is plain transitivity (depend on a node that carries shared deps -> inherit them as secondary deps), so there is no bundle-expansion pass and no DependencyBundle type. Scope-derivation (tenant field -> edges) is the only real derivation. Add an explicit anti-pattern note; rework the walkthrough to the core-services shared-node example. Co-Authored-By: Chris Roadfeldt <chris@roadfeldt.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documents how DCM resolves dependencies — authored several ways (direct edge, component chain, or routed through a shared node) and inserted several ways (authored/discovered/derived/provider/policy) — into one effective graph that consumers (ordered shutdown/startup, topology, blast-radius) run on. Includes the resolution pass, cycle detection, and best-practice granularity guidance.
The one real derivation is scope (a
tenant_uuidis a field, not an edge, so the resolver injects the realm's identity/DNS). Everything else is already ordinary edges: component chains (host → PSU → feed) and bundling — depend on a node that carries shared deps and you inherit them transitively — need no expansion pass. That is why there is noDependencyBundletype: it would reproduce transitivity for no gain. The doc carries the anti-pattern note explaining this.Pairs with the UDLM data-model side: #67 (merged — the dependency-modeling type set: PowerSupply, Location) and croadfeldt/udlm#68 (retires the
DependencyBundletype as an anti-pattern and addsdocs/dependency-modeling.md+ the anonymized examples this walkthrough references).