<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Clean-Architecture on ppl-blog</title><link>https://rifqi-blog.vercel.app/tags/clean-architecture/</link><description>Recent content in Clean-Architecture on ppl-blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 21 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://rifqi-blog.vercel.app/tags/clean-architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Three SOLID Principles, One Design Decision: OCP, ISP, and LSP in a Real FastAPI Service</title><link>https://rifqi-blog.vercel.app/posts/three-solid-principles-one-protocol/</link><pubDate>Thu, 21 May 2026 00:00:00 +0000</pubDate><guid>https://rifqi-blog.vercel.app/posts/three-solid-principles-one-protocol/</guid><description>&lt;p&gt;Most SOLID explainers cover all five principles in one pass, give you a definition and a toy example for each, and move on. What they skip is showing up in a codebase that already works, finding where a principle is being violated, and making the case that fixing it actually changed anything.&lt;/p&gt;
&lt;p&gt;This post focuses on three: OCP, ISP, and LSP. They came up together in a single design decision on a FastAPI invoice-reminder service — and the interesting thing is that one construct in Python&amp;rsquo;s type system addresses all three at once.&lt;/p&gt;</description></item></channel></rss>