<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on Shaaf's blog</title><link>https://shaaf.dev/tags/architecture/</link><description>Recent content in Architecture on Shaaf's blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 09 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://shaaf.dev/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Enforcing Architecture with rgctl Policy Checks</title><link>https://shaaf.dev/post/2026-09-09-enforcing-architecture-with-rgctl-policy-checks/</link><pubDate>Wed, 09 Sep 2026 00:00:00 +0000</pubDate><guid>https://shaaf.dev/post/2026-09-09-enforcing-architecture-with-rgctl-policy-checks/</guid><description>&lt;h1 id="enforcing-architecture-with-rgctl-policy-checks">Enforcing Architecture with rgctl Policy Checks&lt;/h1>
&lt;p>&lt;a href="https://github.com/sshaaf/rgctl">rgctl&lt;/a> (Reachability Graph Control) indexes a codebase into a compact knowledge graph &amp;ndash; functions, classes, calls, inheritance, communities &amp;ndash; and serves deterministic, structured answers to questions about architecture, impact, and data flow. You run &lt;code>rgctl discover .&lt;/code> once, and every subsequent query (&lt;code>blast-radius&lt;/code>, &lt;code>metrics&lt;/code>, &lt;code>gql&lt;/code>) returns sub-millisecond results from the persisted graph. Agents and humans get the same exact facts. No re-reading source files, no confident guesses, no context window gymnastics.&lt;/p></description></item><item><title>Introducing rgctl: A Code Knowledge Graph for Engineering Teams and Agents</title><link>https://shaaf.dev/post/2026-09-07-introducing-rgctl-a-code-knowledge-graph-for-engineering-teams-and-agents/</link><pubDate>Mon, 07 Sep 2026 00:00:00 +0000</pubDate><guid>https://shaaf.dev/post/2026-09-07-introducing-rgctl-a-code-knowledge-graph-for-engineering-teams-and-agents/</guid><description>&lt;h1 id="introducing-rgctl-a-code-knowledge-graph-for-engineering-teams-and-agents">Introducing rgctl: A Code Knowledge Graph for Engineering Teams and Agents&lt;/h1>
&lt;p>Modern codebases are too large to hold in your head. They are also too large for most LLM context windows. When a coding agent needs to answer &amp;ldquo;what breaks if I change this function?&amp;rdquo; on a repository with 50,000 functions, its options are limited: grep through files, read a handful of them, and produce a confident answer that may be structurally wrong.&lt;/p></description></item><item><title>Decomposing a Monolith into Microservices with Call Graph Analysis</title><link>https://shaaf.dev/post/decomposing-a-monolith-into-microservices-with-call-graph-analysis/</link><pubDate>Tue, 01 Sep 2026 00:00:00 +0000</pubDate><guid>https://shaaf.dev/post/decomposing-a-monolith-into-microservices-with-call-graph-analysis/</guid><description>&lt;h1 id="decomposing-a-monolith-into-microservices-with-call-graph-analysis">Decomposing a Monolith into Microservices with Call Graph Analysis&lt;/h1>
&lt;p>Splitting a monolith into microservices is a problem of finding boundaries. The
wrong boundaries produce distributed monoliths &amp;ndash; microservices that cannot be
deployed independently because they call each other synchronously for every
operation. The right boundaries follow natural seams in the code: clusters of
functions that are tightly coupled internally but loosely connected to the rest
of the system. This post picks up the CoolStore monolith from
&lt;a href="https://shaaf.dev/post/migrating-coolstore-monolith-to-quarkus-with-rgctl/">migrating it to Quarkus with rgctl&lt;/a>
and applies the same graph analysis to the next question: where to cut it into
services.&lt;/p></description></item></channel></rss>