<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software-Architecture on Scholion</title><link>https://scholion.thluiz.com/tags/software-architecture/</link><description>Recent content in Software-Architecture on Scholion</description><generator>Hugo -- gohugo.io</generator><language>pt-BR</language><copyright>© 2026</copyright><lastBuildDate>Wed, 23 Sep 2026 20:10:34 +0100</lastBuildDate><atom:link href="https://scholion.thluiz.com/tags/software-architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Avoiding Identity Obsession in .NET with Entity Framework Core</title><link>https://scholion.thluiz.com/notes/avoiding-identity-obsession-in-dotnet-with-entity-framework-core/</link><pubDate>Wed, 23 Sep 2026 19:35:55 +0100</pubDate><guid>https://scholion.thluiz.com/notes/avoiding-identity-obsession-in-dotnet-with-entity-framework-core/</guid><description>Peter Ritchie shows how to configure EF Core shadow properties so a database-required primary key never leaks into a Domain-Driven Design entity&amp;rsquo;s own model.</description></item><item><title>Micro And Macro Software Architectures, Why You Need Both</title><link>https://scholion.thluiz.com/notes/micro-and-macro-software-architectures/</link><pubDate>Wed, 23 Sep 2026 19:08:24 +0100</pubDate><guid>https://scholion.thluiz.com/notes/micro-and-macro-software-architectures/</guid><description>Draws the line between macro architecture decisions a company makes once for everyone and micro architecture decisions each team makes for itself, and argues both need to be explicit.</description></item><item><title>Cross-App Communication with RPC in Elixir</title><link>https://scholion.thluiz.com/notes/cross-app-communication-with-rpc-in-elixir/</link><pubDate>Wed, 23 Sep 2026 19:05:10 +0100</pubDate><guid>https://scholion.thluiz.com/notes/cross-app-communication-with-rpc-in-elixir/</guid><description>How Gearflow connects two Phoenix apps over distributed Erlang RPC instead of HTTP, and the coupling trade-off they accepted to skip building an internal API.</description></item><item><title>EP130: Design a System Like YouTube</title><link>https://scholion.thluiz.com/notes/ep130-design-a-system-like-youtube/</link><pubDate>Wed, 23 Sep 2026 18:49:10 +0100</pubDate><guid>https://scholion.thluiz.com/notes/ep130-design-a-system-like-youtube/</guid><description>Covers eight Software Development Life Cycle models and a 9-step pipeline for a YouTube-like video system, from upload through transcoding to CDN delivery.</description></item><item><title>EP118: What are the differences among database locks?</title><link>https://scholion.thluiz.com/notes/ep118-what-are-the-differences-among-database-locks/</link><pubDate>Wed, 23 Sep 2026 18:46:15 +0100</pubDate><guid>https://scholion.thluiz.com/notes/ep118-what-are-the-differences-among-database-locks/</guid><description>A five-topic system design refresher: database lock types, six pagination techniques, MVC-family architecture patterns, what happens on a URL request, and QR code payments.</description></item><item><title>Did contexts kill Phoenix?</title><link>https://scholion.thluiz.com/notes/did-contexts-kill-phoenix/</link><pubDate>Wed, 23 Sep 2026 18:36:05 +0100</pubDate><guid>https://scholion.thluiz.com/notes/did-contexts-kill-phoenix/</guid><description>Argues that Phoenix&amp;rsquo;s contexts layer, meant to enforce domain-driven boundaries, raised the barrier to entry enough to slow the framework&amp;rsquo;s adoption relative to Rails.</description></item><item><title>Understanding Pure Domain Modelling</title><link>https://scholion.thluiz.com/notes/understanding-pure-domain-modelling/</link><pubDate>Wed, 23 Sep 2026 18:19:19 +0100</pubDate><guid>https://scholion.thluiz.com/notes/understanding-pure-domain-modelling/</guid><description>Argues that domain experts default to describing their existing system rather than the real domain, and proposes asking &amp;lsquo;what would you do without a system?&amp;rsquo; to get past that bias.</description></item><item><title>Refactoring to Serverless: From Application to Automation</title><link>https://scholion.thluiz.com/notes/refactoring-to-serverless-from-application-to-automation/</link><pubDate>Wed, 23 Sep 2026 18:15:35 +0100</pubDate><guid>https://scholion.thluiz.com/notes/refactoring-to-serverless-from-application-to-automation/</guid><description>AWS engineers propose &amp;lsquo;serverless refactoring&amp;rsquo;: moving logic like event publishing out of application code and into automation code (CDK, Lambda Destinations) to separate business logic from topology.</description></item><item><title>From Microservices to Modular Monoliths</title><link>https://scholion.thluiz.com/notes/from-microservices-to-modular-monoliths/</link><pubDate>Wed, 23 Sep 2026 18:08:37 +0100</pubDate><guid>https://scholion.thluiz.com/notes/from-microservices-to-modular-monoliths/</guid><description>Argues that teams stuck in microservice hell should migrate back to modular monoliths, keeping modularity without distributed-system overhead.</description></item><item><title>Architecture Is a Game of Constraint Satisfaction</title><link>https://scholion.thluiz.com/notes/architecture-is-a-game-of-constraint-satisfaction/</link><pubDate>Wed, 23 Sep 2026 17:58:16 +0100</pubDate><guid>https://scholion.thluiz.com/notes/architecture-is-a-game-of-constraint-satisfaction/</guid><description>Gregor Hohpe argues architects keep designing around constraints (procurement lead times, hardware size, coupling costs) long after the constraint that justified them has quietly disappeared.</description></item><item><title>The Publish Pattern</title><link>https://scholion.thluiz.com/notes/the-publish-pattern/</link><pubDate>Wed, 23 Sep 2026 17:30:10 +0100</pubDate><guid>https://scholion.thluiz.com/notes/the-publish-pattern/</guid><description>A concurrency pattern for decoupling producers and consumers using a const shared_ptr, avoiding mutex bottlenecks while keeping the consumer always on the latest published version.</description></item><item><title>Four Layer Architecture</title><link>https://scholion.thluiz.com/notes/four-layer-architecture/</link><pubDate>Wed, 23 Sep 2026 17:20:05 +0100</pubDate><guid>https://scholion.thluiz.com/notes/four-layer-architecture/</guid><description>A pattern from the c2 wiki splits client-server apps into View, ApplicationModel, DomainModel and Infrastructure, extending MVC to cover persistence and the outside world.</description></item><item><title>33/60 Days System Design Questions</title><link>https://scholion.thluiz.com/notes/33-60-days-system-design-questions/</link><pubDate>Wed, 23 Sep 2026 14:47:00 +0100</pubDate><guid>https://scholion.thluiz.com/notes/33-60-days-system-design-questions/</guid><description>A daily.dev system design prompt: an order service that only stores current state can&amp;rsquo;t reconstruct a billing dispute, and the post argues event sourcing is the real fix, not a patch.</description></item></channel></rss>