<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Archyl Architecture Glossary</title>
    <link>https://www.archyl.com/glossary</link>
    <description>Curated definitions of C4 model, DORA metrics, ADR, architecture drift, and other software architecture terms.</description>
    <language>en</language>
    <lastBuildDate>Tue, 21 Apr 2026 20:35:58 GMT</lastBuildDate>
    <atom:link href="https://www.archyl.com/glossary/rss.xml" rel="self" type="application/rss+xml" />
    <image>
      <url>https://www.archyl.com/og-image.png</url>
      <title>Archyl Architecture Glossary</title>
      <link>https://www.archyl.com/glossary</link>
    </image>
    <item>
      <title>C4 Model</title>
      <link>https://www.archyl.com/glossary/c4-model</link>
      <description>A lightweight architecture visualization approach that describes software systems across four levels: System Context, Container, Component, and Code.</description>
      <content:encoded><![CDATA[The C4 model, created by Simon Brown, provides a hierarchical way to describe and communicate software architecture. It uses four levels of abstraction — System Context (level 1), Container (level 2), Component (level 3), and Code (level 4) — to let teams progressively zoom from a high-level view down to implementation details. It is map-like: each diagram has a clear purpose, audience, and level of detail, which avoids the common problem of trying to cram every concern into one box-and-line picture.]]></content:encoded>
      <category>c4-model</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/c4-model</guid>
    </item>
    <item>
      <title>System Context Diagram</title>
      <link>https://www.archyl.com/glossary/system-context-diagram</link>
      <description>C4 level 1 diagram showing a software system and its interactions with users and other external systems.</description>
      <content:encoded><![CDATA[The System Context diagram is the entry point of a C4 model. It focuses on people and external systems that interact with the software system being described, deliberately omitting internal structure. Its goal is to establish scope and audience: who uses the system, which systems it depends on, and which systems depend on it.]]></content:encoded>
      <category>c4-model</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/system-context-diagram</guid>
    </item>
    <item>
      <title>Container Diagram</title>
      <link>https://www.archyl.com/glossary/container-diagram</link>
      <description>C4 level 2 diagram showing the deployable/executable units (applications, services, databases) that make up a software system.</description>
      <content:encoded><![CDATA[A Container in C4 terms is a runtime-level building block: a web app, an API service, a database, a message broker. The Container diagram shows how these pieces fit together, the protocols between them, and the technology choices. It is the most used C4 level in practice because it maps cleanly to what platform and infrastructure teams deploy.]]></content:encoded>
      <category>c4-model</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/container-diagram</guid>
    </item>
    <item>
      <title>Component Diagram</title>
      <link>https://www.archyl.com/glossary/component-diagram</link>
      <description>C4 level 3 diagram decomposing a container into groups of related functionality (components) and their collaborations.</description>
      <content:encoded><![CDATA[The Component diagram opens up one container and reveals the components inside — higher-level groupings of code (controllers, services, repositories, etc.) that have a single responsibility. Unlike a class diagram, a C4 Component is an abstraction, not necessarily a 1:1 mapping to a programming-language class.]]></content:encoded>
      <category>c4-model</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/component-diagram</guid>
    </item>
    <item>
      <title>Code Diagram</title>
      <link>https://www.archyl.com/glossary/code-diagram</link>
      <description>C4 level 4 diagram showing the implementation-level details (classes, interfaces, functions) of a component.</description>
      <content:encoded><![CDATA[The Code diagram is the lowest level of the C4 model and is usually generated from code rather than drawn by hand. Many teams skip it entirely unless they need to explain a particularly intricate component, since IDEs and source code already expose this level.]]></content:encoded>
      <category>c4-model</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/code-diagram</guid>
    </item>
    <item>
      <title>Architecture Decision Record (ADR)</title>
      <link>https://www.archyl.com/glossary/architecture-decision-record</link>
      <description>A short document capturing a single architecturally significant decision, its context, and its consequences.</description>
      <content:encoded><![CDATA[An ADR makes a decision legible to future teammates. It typically records the context (what forces were at play), the decision, the alternatives considered, and the consequences (trade-offs you are now living with). ADRs are versioned alongside the code and are superseded rather than edited — the history of thinking is as valuable as the current answer.]]></content:encoded>
      <category>documentation</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/architecture-decision-record</guid>
    </item>
    <item>
      <title>Architecture Drift</title>
      <link>https://www.archyl.com/glossary/architecture-drift</link>
      <description>The widening gap between documented architecture and the system that actually runs in production.</description>
      <content:encoded><![CDATA[Drift is unavoidable: code evolves, services are added, responsibilities shift. If documentation is not continuously reconciled with the codebase, it becomes a lie — or worse, an authoritative-looking lie. Drift detection tools compare what the docs say against what the code shows and produce a conformance score you can track over time.]]></content:encoded>
      <category>practices</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/architecture-drift</guid>
    </item>
    <item>
      <title>Conformance Rule</title>
      <link>https://www.archyl.com/glossary/conformance-rule</link>
      <description>A machine-checkable constraint that validates the codebase against architectural intent.</description>
      <content:encoded><![CDATA[A conformance rule encodes an architectural invariant as code: "the domain layer must not import from the infrastructure layer", "every public endpoint must declare an owning team", "no service may call the payments database directly". Running these rules in CI gives teams a safety net that catches drift at PR time rather than during a painful audit six months later.]]></content:encoded>
      <category>practices</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/conformance-rule</guid>
    </item>
    <item>
      <title>Architecture as Code</title>
      <link>https://www.archyl.com/glossary/architecture-as-code</link>
      <description>Describing system architecture in a versioned, text-based format so it can be reviewed, diffed, and validated like source code.</description>
      <content:encoded><![CDATA[Architecture as Code treats diagrams and models as derived artifacts of a source-of-truth file (YAML, DSL, or similar). The benefits are the familiar ones of infrastructure-as-code: pull-request review, CI validation, drift detection, and a single history where architecture and implementation change together.]]></content:encoded>
      <category>practices</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/architecture-as-code</guid>
    </item>
    <item>
      <title>Technology Radar</title>
      <link>https://www.archyl.com/glossary/technology-radar</link>
      <description>A curated catalog of technologies grouped into rings (adopt / trial / assess / hold) that guides engineering choices.</description>
      <content:encoded><![CDATA[Popularized by Thoughtworks, a Technology Radar lets an engineering organization make its stance on tools and techniques explicit. Each entry is scored, discussed, and placed in a ring. Teams consult it before picking a new dependency, which shortens debates and produces a visible, maintained position on the tech landscape.]]></content:encoded>
      <category>practices</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/technology-radar</guid>
    </item>
    <item>
      <title>DORA Metrics</title>
      <link>https://www.archyl.com/glossary/dora-metrics</link>
      <description>Four widely used engineering performance metrics: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery.</description>
      <content:encoded><![CDATA[The DORA research program (Accelerate, State of DevOps Report) identified four metrics that correlate with high-performing software teams. Tracking them exposes whether architecture decisions — coupling, deployability, observability — help or hurt real outcomes. DORA is diagnostic: the numbers are a prompt for the next conversation, not a leaderboard.]]></content:encoded>
      <category>dora</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/dora-metrics</guid>
    </item>
    <item>
      <title>Deployment Frequency</title>
      <link>https://www.archyl.com/glossary/deployment-frequency</link>
      <description>How often a team successfully ships code to production. One of the four DORA metrics.</description>
      <content:encoded><![CDATA[Deployment Frequency answers the question: how often is new value reaching users? Elite teams deploy on demand, sometimes many times a day; low performers deploy less than once a month. Low frequency is usually a symptom of tight coupling, brittle tests, or manual gates that architecture choices can address.]]></content:encoded>
      <category>dora</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/deployment-frequency</guid>
    </item>
    <item>
      <title>Lead Time for Changes</title>
      <link>https://www.archyl.com/glossary/lead-time-for-changes</link>
      <description>The time between a code change being committed and that change running in production.</description>
      <content:encoded><![CDATA[Lead Time captures the full delivery path: review, CI, staging, release. Architectural choices dominate this metric — a monolith with slow tests and a manual release train will dwarf small, well-factored services with a progressive delivery pipeline, regardless of individual coder speed.]]></content:encoded>
      <category>dora</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/lead-time-for-changes</guid>
    </item>
    <item>
      <title>Change Failure Rate</title>
      <link>https://www.archyl.com/glossary/change-failure-rate</link>
      <description>The percentage of deployments that cause a degradation in production and require remediation.</description>
      <content:encoded><![CDATA[Change Failure Rate is the honesty check on Deployment Frequency: shipping fast does not help if most ships break something. Architectural investments in isolation (small blast radius), observability, and feature flags typically move this number.]]></content:encoded>
      <category>dora</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/change-failure-rate</guid>
    </item>
    <item>
      <title>Mean Time to Recovery (MTTR)</title>
      <link>https://www.archyl.com/glossary/mean-time-to-recovery</link>
      <description>The average time it takes to restore service after a production incident.</description>
      <content:encoded><![CDATA[MTTR is often a better indicator of system resilience than incident count. Fast recovery implies good observability, clear ownership, and safe rollback paths — all of which are architecture decisions more than operational heroics.]]></content:encoded>
      <category>dora</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/mean-time-to-recovery</guid>
    </item>
    <item>
      <title>Domain-Driven Design (DDD)</title>
      <link>https://www.archyl.com/glossary/domain-driven-design</link>
      <description>An approach to software design that centers the model and language of the business domain.</description>
      <content:encoded><![CDATA[DDD, introduced by Eric Evans, argues that the hard part of most software is modeling the domain, and that the code and the conversation with domain experts should share a ubiquitous language. Tactical patterns (entity, value object, aggregate) help implement the model; strategic patterns (bounded context, context map) help carve a large system into parts teams can own.]]></content:encoded>
      <category>architecture</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/domain-driven-design</guid>
    </item>
    <item>
      <title>Hexagonal Architecture</title>
      <link>https://www.archyl.com/glossary/hexagonal-architecture</link>
      <description>A layered architecture style that isolates domain logic from infrastructure via ports and adapters.</description>
      <content:encoded><![CDATA[Hexagonal (a.k.a. ports and adapters) treats the domain as the center and surrounds it with ports — interfaces it uses to reach the outside world — and adapters — implementations of those ports for specific tech (HTTP, SQL, Kafka). The payoff is a domain that is testable in isolation and infrastructure that can be swapped without touching business rules.]]></content:encoded>
      <category>architecture</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/hexagonal-architecture</guid>
    </item>
    <item>
      <title>Clean Architecture</title>
      <link>https://www.archyl.com/glossary/clean-architecture</link>
      <description>A layered architecture where dependencies point inward toward the domain, popularized by Robert C. Martin.</description>
      <content:encoded><![CDATA[Clean Architecture is a generalization of hexagonal and onion architectures. Its core rule is the Dependency Rule: source code dependencies can only point inward. The domain knows nothing about frameworks or databases; frameworks and databases know how to adapt to the domain.]]></content:encoded>
      <category>architecture</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/clean-architecture</guid>
    </item>
    <item>
      <title>Event Storming</title>
      <link>https://www.archyl.com/glossary/event-storming</link>
      <description>A collaborative modeling workshop that uses sticky notes representing domain events to map a business process.</description>
      <content:encoded><![CDATA[Event Storming, introduced by Alberto Brandolini, is a fast way to get everyone who knows something about a domain in a room (physical or virtual) and produce a shared model. It is especially effective at surfacing hidden complexity and at seeding DDD bounded contexts.]]></content:encoded>
      <category>practices</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/event-storming</guid>
    </item>
    <item>
      <title>Microservices</title>
      <link>https://www.archyl.com/glossary/microservices</link>
      <description>An architectural style that structures an application as a collection of small, independently deployable services organized around business capabilities.</description>
      <content:encoded><![CDATA[Microservices trade internal complexity (one large codebase) for distributed complexity (many small ones that must coordinate). The trade is worthwhile when teams need independent cadence and clear ownership — and punishing when a distributed system is built without the operational maturity to run it.]]></content:encoded>
      <category>architecture</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/microservices</guid>
    </item>
    <item>
      <title>Service Mesh</title>
      <link>https://www.archyl.com/glossary/service-mesh</link>
      <description>A dedicated infrastructure layer for handling service-to-service communication, typically via sidecar proxies.</description>
      <content:encoded><![CDATA[A service mesh (Istio, Linkerd, Consul) takes concerns like mTLS, retries, timeouts, and traffic shaping out of application code and into the platform. Every service gets the same networking behavior, and platform teams can change policy centrally without touching application code.]]></content:encoded>
      <category>architecture</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/service-mesh</guid>
    </item>
    <item>
      <title>API Contract</title>
      <link>https://www.archyl.com/glossary/api-contract</link>
      <description>A formal specification of an API (OpenAPI, gRPC proto, GraphQL schema) that producers and consumers agree to uphold.</description>
      <content:encoded><![CDATA[An API contract turns an interface from tribal knowledge into a versioned artifact. It enables client-generated code, compatibility checks in CI, and consumer-driven contract tests. For inter-team coordination it is one of the highest-leverage documentation pieces an architecture can own.]]></content:encoded>
      <category>practices</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/api-contract</guid>
    </item>
    <item>
      <title>Event Channel</title>
      <link>https://www.archyl.com/glossary/event-channel</link>
      <description>A named, typed stream of events (often Kafka topic or equivalent) through which services publish and subscribe asynchronously.</description>
      <content:encoded><![CDATA[Event channels are the async counterpart of API contracts. Documenting them — schema, ordering guarantees, retention, owner — turns a fragile implicit integration into a first-class interface that producers and consumers can evolve independently.]]></content:encoded>
      <category>practices</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/event-channel</guid>
    </item>
    <item>
      <title>Ownership Map</title>
      <link>https://www.archyl.com/glossary/ownership-map</link>
      <description>A mapping from system elements (services, modules, pipelines) to the team or person accountable for them.</description>
      <content:encoded><![CDATA[Ownership is the single most important metadata a large codebase can carry. When an incident, a security alert, or a dependency upgrade lands, the first question is always "who owns this?" — and an ownership map turns that from a 20-minute archaeology dig into a one-click lookup.]]></content:encoded>
      <category>documentation</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/ownership-map</guid>
    </item>
    <item>
      <title>Living Documentation</title>
      <link>https://www.archyl.com/glossary/living-documentation</link>
      <description>Documentation that is generated or validated from the running system, so it stays accurate as the system evolves.</description>
      <content:encoded><![CDATA[Living documentation, introduced by Cyrille Martraire, rejects the premise that docs have to rot. The idea: treat documentation as an output of the codebase (extracted, generated, or continuously validated) rather than as a parallel artifact that someone has to remember to update. C4 models discovered from code and conformance rules enforced in CI are both instances of this idea.]]></content:encoded>
      <category>documentation</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/living-documentation</guid>
    </item>
    <item>
      <title>MCP Server</title>
      <link>https://www.archyl.com/glossary/mcp-server</link>
      <description>A server implementing the Model Context Protocol so AI coding assistants can query project context through a standardized tool interface.</description>
      <content:encoded><![CDATA[The Model Context Protocol (MCP) lets AI assistants like Claude or Cursor call into external data and tools through a well-defined protocol rather than ad hoc plug-ins. For architecture, an MCP server exposes systems, containers, ADRs, and conformance data so the assistant can ground its answers in your real model — not a hallucination of what similar projects look like.]]></content:encoded>
      <category>practices</category>
      <pubDate>Tue, 21 Apr 2026 20:35:58 GMT</pubDate>
      <guid isPermaLink="true">https://www.archyl.com/glossary/mcp-server</guid>
    </item>
  </channel>
</rss>