<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:media="http://search.yahoo.com/mrss/"><channel><title>architecture on Carrion.dev</title><link>https://carrion.dev/en/tags/architecture/</link><description>Recent content in architecture on Carrion.dev</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>ignacio@carrion.dev (Ignacio Carrión)</managingEditor><webMaster>ignacio@carrion.dev (Ignacio Carrión)</webMaster><copyright>&amp;copy;{year}, All Rights Reserved</copyright><lastBuildDate>Fri, 22 Aug 2025 08:00:00 +0100</lastBuildDate><atom:link href="https://carrion.dev/en/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Dependency Injection + Dependency Inversion: More Robust and Testable Code</title><link>https://carrion.dev/en/posts/dependency-injection-benefits/</link><pubDate>Fri, 22 Aug 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Fri, 22 Aug 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/dependency-injection-benefits/</guid><description>Dependency Injection + Dependency Inversion: More Robust and Testable Code Modern applications evolve quickly: features are added, platforms multiply, and teams scale. In this environment, tightly coupled code becomes a bottleneck for change and a source of fragile tests. Two key ideas help us fight this complexity:
Dependency Inversion Principle (DIP) from SOLID: high-level modules should not depend on low-level modules. Both should depend on abstractions. Dependency Injection (DI): a technique and set of tools to provide those dependencies from the outside instead of constructing them internally.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/dip.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>architecture</category><category>solid</category><category>dependency-injection</category><category>testing</category></item><item><title>DataSources and Repository Patterns: Building a Robust Data Layer</title><link>https://carrion.dev/en/posts/datasources-repository-patterns/</link><pubDate>Fri, 13 Jun 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Fri, 13 Jun 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/datasources-repository-patterns/</guid><description>DataSources and Repository Patterns: Building a Robust Data Layer In modern application development, managing data access efficiently is crucial for creating maintainable and scalable software. Two architectural patterns that significantly improve data management are the DataSource and Repository patterns. This blog post explores what these patterns are, how they work together, and how to implement them effectively with practical examples.
What Are DataSources? DataSources are components responsible for handling data operations with a specific data origin.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/repository.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>architecture</category><category>clean-architecture</category><category>repository-pattern</category><category>datasources</category><category>software-design</category></item><item><title>UseCases: Improving Your Project Architecture</title><link>https://carrion.dev/en/posts/usecases-architecture/</link><pubDate>Fri, 06 Jun 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Fri, 06 Jun 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/usecases-architecture/</guid><description>UseCases: Improving Your Project Architecture In modern software development, creating maintainable, testable, and scalable applications is a constant challenge. One architectural pattern that has gained significant traction is the use of UseCases. This blog post explores what UseCases are, why they improve your project&amp;rsquo;s architecture, and how to implement them effectively with simple examples.
What Are UseCases? UseCases represent the business logic or application-specific rules of your software. They encapsulate a single, specific action that can be performed in your application.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/usecase.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>architecture</category><category>clean-architecture</category><category>usecases</category><category>software-design</category></item><item><title>Leveraging Sealed Classes and Interfaces for Better Domain Modeling</title><link>https://carrion.dev/en/posts/sealed-classes-domain-modeling/</link><pubDate>Tue, 15 Apr 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Tue, 15 Apr 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/sealed-classes-domain-modeling/</guid><description>Leveraging Sealed Classes and Interfaces for Better Domain Modeling Domain modeling is a crucial aspect of software development, representing the core business concepts and rules in your application. Kotlin provides powerful language features that can help create more expressive, type-safe, and maintainable domain models. Among these features, sealed classes and interfaces stand out as particularly valuable tools. This blog post explores how to leverage these Kotlin features to build better domain models.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/sealed-classes.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>architecture</category><category>domain modeling</category><category>type safety</category></item><item><title>Composition Over Inheritance: A Kotlin Perspective</title><link>https://carrion.dev/en/posts/composition-over-inheritance/</link><pubDate>Fri, 11 Apr 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Fri, 11 Apr 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/composition-over-inheritance/</guid><description>Composition Over Inheritance: A Kotlin Perspective In object-oriented programming, there are two primary ways to reuse code and establish relationships between classes: inheritance and composition. While both approaches have their place, the principle of &amp;ldquo;composition over inheritance&amp;rdquo; has gained significant traction in modern software design. This blog post explores both approaches, their trade-offs, and why composition is often the preferred choice, with examples in Kotlin.
Understanding Inheritance Inheritance is a mechanism where a class (subclass) can inherit properties and behaviors from another class (superclass).</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/composition-inheritance.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>architecture</category><category>design patterns</category><category>object-oriented programming</category></item><item><title>Kotlin Multiplatform Architecture Best Practices for Mobile Apps</title><link>https://carrion.dev/en/posts/kmp-architecture/</link><pubDate>Tue, 11 Feb 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Tue, 11 Feb 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/kmp-architecture/</guid><description>Kotlin Multiplatform Architecture Best Practices for Mobile Apps Kotlin Multiplatform (KMP) allows developers to share business logic between Android and iOS while keeping platform-specific implementations where necessary. Structuring a KMP project efficiently is key to maintaining scalability, testability, and clean architecture. In this guide, we’ll explore best practices for architecting a KMP mobile application with Compose Multiplatform and Clean Architecture.
1. Project Structure A well-organized project structure improves maintainability and separation of concerns.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/expect-actual.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>compose</category><category>cmp</category><category>multiplatform</category><category>cleancode</category><category>architecture</category></item><item><title>Boosting Android App Performance with Baseline Profiles</title><link>https://carrion.dev/en/posts/baseline-profiles/</link><pubDate>Mon, 27 Jan 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Mon, 27 Jan 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/baseline-profiles/</guid><description>Boosting Android App Performance with Baseline Profiles Introduction In today’s fast-paced mobile world, users expect apps to launch instantly and run smoothly. Performance optimization is crucial, especially concerning app startup time and runtime execution.
Android’s Baseline Profiles offer an effective way to speed up app startup and improve runtime performance by precompiling critical code paths. Google Play even recommends using Baseline Profiles to enhance the user experience, particularly for apps with complex UI rendering or heavy dependencies.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/baseline-profile.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>architecture</category></item><item><title>Modularization in Gradle Projects with Kotlin</title><link>https://carrion.dev/en/posts/gradle-modularization/</link><pubDate>Thu, 23 Jan 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Thu, 23 Jan 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/gradle-modularization/</guid><description>Modularization in Gradle Projects with Kotlin: A Comprehensive Guide Introduction As projects grow in complexity, maintaining a monolithic codebase becomes challenging. Modularization is a software design technique that breaks down an application into smaller, independent modules, making the project more scalable, maintainable, and efficient.
In this guide, we’ll explore why modularization is essential, different types of modules, and best practices for setting up a modular Gradle project using Kotlin.
Why Modularization?</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/folder-structure.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>architecture</category></item><item><title>Test-Driven Development (TDD) in Kotlin for Android</title><link>https://carrion.dev/en/posts/tdd-kotlin/</link><pubDate>Mon, 20 Jan 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Mon, 20 Jan 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/tdd-kotlin/</guid><description>Test-Driven Development (TDD) in Kotlin for Android Test-Driven Development (TDD) is a software development practice that emphasizes writing tests before implementing functionality. It follows a Red-Green-Refactor cycle: first, you write a failing test (Red), then implement just enough code to make it pass (Green), and finally, refactor the code while keeping the test green (Refactor). In this post, we&amp;rsquo;ll explore how to apply TDD in Kotlin for Android development using JUnit, MockK, and Coroutines with a real-world example.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/tdd-cycle.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>architecture</category><category>TDD</category><category>testing</category></item><item><title>Clean Architecture in Kotlin &amp; Android</title><link>https://carrion.dev/en/posts/clean-architecture/</link><pubDate>Sat, 18 Jan 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Sat, 18 Jan 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/clean-architecture/</guid><description>Clean Architecture in Kotlin &amp;amp; Android Introduction When building Android applications, maintaining scalability and readability is crucial. Without a clear architectural approach, projects can become difficult to maintain as they grow. This is where Clean Architecture, introduced by Uncle Bob (Robert C. Martin), becomes invaluable. It emphasizes separation of concerns, making code more modular, testable, and maintainable.
Understanding Clean Architecture Clean Architecture is structured into three main layers, each with a specific role:</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/domain-layer.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>architecture</category></item><item><title>Exploring App Architectures in Kotlin</title><link>https://carrion.dev/en/posts/app-architecture/</link><pubDate>Wed, 15 Jan 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Wed, 15 Jan 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/app-architecture/</guid><description>Exploring App Architectures in Kotlin: MVC, MVP, MVVM, and MVI Introduction In modern app development, choosing the right architecture is essential for creating maintainable and scalable applications. Architectures define how your codebase is organized and how different components interact. In this post, we’ll explore four popular app architectures: Model-View-Controller (MVC), Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), and Model-View-Intent (MVI). We’ll look at their structure, pros, cons, and practical examples in Kotlin.
1. Model-View-Controller (MVC) Definition:</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/mvvm.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>architecture</category></item><item><title>Kotlin Design Patterns - Part 3</title><link>https://carrion.dev/en/posts/design-patterns-3/</link><pubDate>Mon, 13 Jan 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Mon, 13 Jan 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/design-patterns-3/</guid><description>Exploring More Design Patterns in Kotlin: Part 3 Design Patterns Series Part 1 Part 2 Part 3 In this third installment, we’ll cover Memento, Command, Visitor, Chain of Responsibility, and Mediator patterns. These patterns address construction, behavioral, and structural challenges, showcasing Kotlin&amp;rsquo;s expressive syntax and modern features.
1. Memento Pattern The Memento Pattern captures and restores an object&amp;rsquo;s state without exposing its internal details.
When to Use To implement undo/redo functionality.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/memento-pattern.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>design-patterns</category><category>architecture</category></item><item><title>Understanding SOLID Principles with Kotlin Examples</title><link>https://carrion.dev/en/posts/solid-kotlin/</link><pubDate>Wed, 08 Jan 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Wed, 08 Jan 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/solid-kotlin/</guid><description>Understanding SOLID Principles with Kotlin Examples The SOLID principles are a set of design principles that make software designs more understandable, flexible, and maintainable. Introduced by Robert C. Martin, these principles are a cornerstone of object-oriented programming and are especially relevant when building complex systems. In this blog post, we’ll explore each principle with examples written in Kotlin, a language that brings modern syntax and powerful features to the table.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/di-fix.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>solid</category><category>architecture</category></item><item><title>Kotlin Design Patterns - Part 2</title><link>https://carrion.dev/en/posts/design-patterns-2/</link><pubDate>Mon, 06 Jan 2025 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Mon, 06 Jan 2025 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/design-patterns-2/</guid><description>Exploring Design Patterns in Kotlin: Part 2 Design Patterns Series Part 1 Part 2 Part 3 After the overwhelming response to our first post on Kotlin design patterns, we’re back with more! In this second part, we’ll dive into Prototype, Composite, Proxy, Observer, and Strategy patterns. These patterns solve a variety of design challenges and demonstrate Kotlin’s expressive capabilities.
1. Prototype Pattern The Prototype Pattern is used to create new objects by copying an existing object, ensuring efficient object creation.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/proxy-pattern.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>design-patterns</category><category>architecture</category></item><item><title>Kotlin Design Patterns - Part 1</title><link>https://carrion.dev/en/posts/design-patterns-1/</link><pubDate>Mon, 30 Dec 2024 08:00:00 +0100</pubDate><author>ignacio@carrion.dev (Ignacio Carrión)</author><atom:modified>Mon, 30 Dec 2024 08:00:00 +0100</atom:modified><guid>https://carrion.dev/en/posts/design-patterns-1/</guid><description>Exploring Design Patterns in Kotlin - Part 1 Design Patterns Series Part 1 Part 2 Part 3 Design patterns are proven solutions to common problems in software design. With Kotlin’s expressive syntax and modern features, implementing these patterns often becomes cleaner and more concise. In this post, we’ll explore Singleton, Factory Method, Builder, Adapter and Decorator patterns, delving into their purpose, use cases, and Kotlin implementations.
1. Singleton Pattern The Singleton Pattern ensures that a class has only one instance and provides a global access point to it.</description><dc:creator>Ignacio Carrión</dc:creator><media:content url="https://carrion.dev/images/kotlin/singleton-pattern.png" medium="image"><media:title type="html">featured image</media:title></media:content><category>kotlin</category><category>design-patterns</category><category>architecture</category></item></channel></rss>