<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Philosophy on original.flipster</title><link>https://originalflipster.com/tags/philosophy/</link><description>Recent content in Philosophy on original.flipster</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026</copyright><lastBuildDate>Wed, 21 Jan 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://originalflipster.com/tags/philosophy/index.xml" rel="self" type="application/rss+xml"/><item><title>Own your Domain before it ends up owning you!</title><link>https://originalflipster.com/rants/own-your-domain-before-it-owns-you/</link><pubDate>Wed, 21 Jan 2026 00:00:00 +0000</pubDate><guid>https://originalflipster.com/rants/own-your-domain-before-it-owns-you/</guid><description>Bugs make Software tumble, but blurred boundaries make it collapse for good. For those structural issues the &amp;lsquo;Domain-Driven-Design&amp;rsquo; label is readily slapped around, but what does that even mean and how put it into practice? The answer is&amp;hellip; deeply philosophical, but worth diving into if you looking for guidance on building systems that make some sense.</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://originalflipster.com/rants/own-your-domain-before-it-owns-you/featured.png"/></item></channel></rss>