Dr.Rec Architecture Framework

• Dr.Rec is a framework for static architectural reconstruction that decomposes complex systems using technology-specific extractors and conflict detection.
• It orchestrates dependency-aware scheduling to generate per-repository JSON models and seamlessly unifies them through rigorous merge algorithms.
• The framework supports extensible, parallel analysis of multi-repository microservices, ensuring up-to-date documentation and accurate inter-service linking.

Dr.Rec (Distributed Architecture Reconstruction) is a framework for static architectural reconstruction of polyglot, multi-repository microservice systems. It facilitates up-to-date architectural documentation by decomposing static analysis into technology-specific extractors, orchestrating these modules via a dependency-aware scheduler, persisting per-repository architectural models, and unifying them into a global architectural view with rigorous conflict detection and retroactive linking. Dr.Rec operates entirely through static analysis, supports parallelization across independently evolving repositories, and is designed for extensibility to support diverse analysis techniques and programming environments (Manglaras et al., 8 Feb 2026).

1. Core Components and High-Level Architecture

Dr.Rec consists of four principal components: Extractors, Orchestration Layer, Data Store (Model Files), and Unification Engine.

• Extractors are technology-specific, stateless functions that accept and return "model entities" (JSON-structured objects representing architectural elements). Examples include Docker-Compose extractors, Java-Spring extractors, YAML/JSON config extractors, and wrappers for tools like ReSSA.
• Orchestration Layer manages extractor invocation using the runExtractors algorithm, enforcing their dependencies, recursively applying eligible extractors to all entities and sub-entities, and ensuring progress to quiescence. The orchestration API provides utilities for file-system scanning, regex parsing, and model entity manipulation.
• Data Store captures each repository's architectural model output as a JSON file conforming to a loose schema (microservices, endpoints, links, etc.), typically generated during CI/CD pipelines.
• Unification Engine merges N per-repository models into a global model, leveraging recursive array-union, map-merging algorithms, and explicit conflict detection. It supports retroactive linking to resolve call relationships after model aggregation.

The following ASCII diagram summarizes component interactions:

$R \subseteq E \times E$1

2. Formal System Model and Dataflow

The formal foundations of Dr.Rec are specified as follows:

• Let $E = \{e_1, e_2, \dots, e_n\}$ denote the set of registered extractors.
• Each extractor $e_i$ processes artifacts from a universe $D = \{d_1, d_2, \dots, d_m\}$.
• A dependency relation $R \subseteq E \times E$ encodes prerequisite ordering: $(e_i, e_j) \in R$ indicates $e_i$ must complete before $e_j$.
• The dependency graph $(E, R)$ is a directed acyclic graph (DAG), enforced by the constraint that for all $e_i$, $(e_i, R^+)$ is acyclic.
• Extractor data contracts are defined as $e_i$0, with $e_i$1 and execution order such that for all $e_i$2, $e_i$3.
• Each repository's model is a set $e_i$4 of observed artifacts, serialized as a JSON file.

This model supports per-entity parallel scheduling of extractors, guarantees single execution of extractors per entity (tracked by UUID), and naturally adapts to distributed, technology-diverse codebases.

3. Orchestration Algorithm and Execution Semantics

The orchestration process is governed by the runExtractors algorithm, formally outlined in the provided pseudocode (see (Manglaras et al., 8 Feb 2026), Sec. 3). The main steps are:

• For each entity and its sub-entities, iterate over extractors whose schema matches the entity type.
• If the extractor has not yet executed on the entity and its preconditions are satisfied, it is invoked as a pure function.
• The output is then merged with the original entity using recursive, conflict-detecting union semantics.
• If the merge introduces non-trivial changes, the extractor scheduling loop continues until quiescence (no further changes).

Complexity for a model with $e_i$5 extractors, $e_i$6 sub-entities, and $e_i$7 passes is $e_i$8, where $e_i$9 is the cost of schema validation plus merge.

Exactly-once execution per extractor-entity pair is enforced by tracking UUIDs in a per-extractor set, supporting parallel and safe scheduling across all subcomponents.

4. Model Unification and Conflict Resolution

Unification of models across repositories builds the global architectural view. Each model $D = \{d_1, d_2, \dots, d_m\}$0 is a partial JSON structure. The goal is to compute $D = \{d_1, d_2, \dots, d_m\}$1, the idempotent union of all per-repo models.

Operators used in model merging:

• mergeScalar: If two scalar values $D = \{d_1, d_2, \dots, d_m\}$2 are equal, the result is $D = \{d_1, d_2, \dots, d_m\}$3; otherwise, a conflict ($D = \{d_1, d_2, \dots, d_m\}$4) is signaled.
• mergeMap: Recursively merges maps by key, applying $D = \{d_1, d_2, \dots, d_m\}$5 to values. If a conflict arises, merging halts with error.
• mergeList: Performs idempotent set-union, recursively merging any pair $D = \{d_1, d_2, \dots, d_m\}$6 for which $D = \{d_1, d_2, \dots, d_m\}$7; unmatched items are appended.

The full merged model is defined as

$D = \{d_1, d_2, \dots, d_m\}$8

This process is commutative, associative, and idempotent.

Conflict resolution is strict: any irreconcilable field difference (e.g., conflicting scalar values) results in error. Extensions to last-writer-wins or priority policies are noted as future possibilities but are not part of the baseline framework.

A key feature is retroactive linking: After merging, inter-service references (e.g., outgoing call links) are resolved by matching endpoints and service identifiers across the unified model.

5. Extensibility: Technology-Specific Extractors and API Design

Extractors are the extensibility mechanism for Dr.Rec. Each extractor is a function with the signature: $R \subseteq E \times E$2 Where:

• ModelEntity is a JSON-structured object (with $$TYPE</code>, <code>UUID</code>, arbitrary keys).</li> <li><code>Api</code> supplies utilities including file discovery, reading, entity creation, and custom parser integration.</li> </ul> <p>Registration of extractors is explicit:$$R \subseteq E \times E$3</p> <p>Extension points include:</p> <ul> <li>Schema-driven selection of target entities for extraction.</li> <li>Reserved fields (matching <code>/^\$D = \{d_1, d_2, \dots, d_m\}$9/</code>) to facilitate inter-extractor communication.</li> <li>Augmentable <code>Api</code> object for hosting new analysis utilities or third-party static analysis tool wrappers.</li> </ul> <p>Execution is stateless (modifying only the returned entity), adheres to per-entity exactly-once semantics, and the parallelizable, DAG-constrained scheduler ensures that dependencies are satisfied before invocation. Extractors can wrap or embed existing <a href="https://www.emergentmind.com/topics/static-analysis-tools" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">static analysis tools</a> and algorithms within their implementation.</p> <h2 class='paper-heading' id='illustrative-example-data-flow-in-multi-repository-microservices'>6. Illustrative Example: Data Flow in Multi-Repository Microservices</h2> <p>Consider two microservice repositories, A and B:</p> <ul> <li><strong>Repo A</strong> contains a Docker-Compose definition for &quot;service-A&quot; exposing &quot;/foo&quot; and &quot;/bar&quot; endpoints.</li> <li><strong>Repo B</strong> is a Spring project implementing &quot;service-B&quot;, which issues HTTP calls to <code>http://service-A/foo</code>.</li> </ul> <p>Running Dr.Rec in each repo yields distinct <code>model.json</code> files:</p> <ul> <li><strong>model_A.json</strong> $R \subseteq E \times E$4</li> <li><strong>model_B.json</strong>$R \subseteq E \times E$5

The Unification Engine performs

$R \subseteq E \times E$0

and retroactively resolves outgoing calls from service-B to the "/foo" endpoint of service-A, thus constructing a fully-linked call graph within the unified model.

7. Significance and Application Scope

Dr.Rec is distinguished by its ability to support distributed, polyglot, multi-repository environments without imposing mono-repo constraints or rigid technology assumptions. By modularizing static analysis into composable extractors and relying on JSON-based model unification with strict conflict detection and explicit linking semantics, Dr.Rec enables CI-driven, incremental, and technology-agnostic architecture reconstruction. This permits organizations to maintain consistent and up-to-date architectural documentation and analysis across highly dynamic microservice ecosystems, facilitating tasks such as documentation, dependency analysis, and architectural visualization (Manglaras et al., 8 Feb 2026).