# architecture-pattern Published articles for architecture-pattern. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A Simple MVI Architecture Approach Using LiveData DevFeed: [A Simple MVI Architecture Approach Using LiveData]() Original publisher: [Read original article]() Author: dustin@dustn.dev (Dustin Summers) Published: 2026-09-17T04:13:15.404035Z Content type: opinion Language: en Sources: [Dustin Summers]() Topics: [Android](), [Dagger]() Tags: [architecture](), [architecture-pattern](), [error](), [livedata](), [loading](), [mvi]() ### AI overview A talk from Android Summit 2019 discusses a simple implementation of the MVI architecture pattern using LiveData and the Loading, Content, Error pattern. ### Source excerpt This was a talk provided by myself and Dan Lowe at Android Summit, 2019. In this we discuss a simple approach to the MVI (Model, View, Intent) Architecture Pattern using LiveData and the common Loading, Content, Error Pattern. Link to Dan's blog post is here which is what our talk was based around. ## A guide to Transformer architecture in modern language models DevFeed: [A guide to Transformer architecture in modern language models]() Original publisher: [Read original article]() Author: Ashish Pratap Singh Published: 2026-05-14T04:15:11Z Content type: tutorial Language: en Sources: [AlgoMaster Newsletter]() Topics: [Transformer architecture](), [LLMs](), [Transformer]() Tags: [architecture-pattern](), [better](), [deep-dive](), [layer](), [llms](), [model](), [parallel](), [performance](), [semantics](), [sequence](), [syntax](), [tokens](), [transformer-architecture](), [transformers]() ### AI overview This tutorial explains the Transformer architecture, including its original encoder-decoder design for translation and the decoder-only variant used for modern language generation. It describes decoder components such as masked multi-head self-attention, feed-forward networks, layer normalization, and residual connections, and introduces the Pre-LayerNorm pattern. ### Source excerpt A single 2017 research paper changed the future of AI forever and gave rise to multiple unicorn companies. ## Patterns & Best Practices in Event-Driven Systems DevFeed: [Patterns & Best Practices in Event-Driven Systems]() Original publisher: [Read original article]() Author: Victor Wenas Published: 2025-12-08T06:14:51Z Content type: tutorial Language: en Sources: [Kogan.com]() Topics: [event driven](), [systems](), [Publish-subscribe pattern]() Tags: [architecture](), [architecture-pattern](), [decoupling](), [event-driven](), [event-sourcing](), [latency](), [patterns](), [systems]() ### AI overview This tutorial explains three event-driven architecture patterns: event notification, Event-Carried State Transfer, and Event Sourcing. It describes their trade-offs, including service coupling, additional data fetches, payload size, schema management, resilience, and latency. ### Source excerpt Designing Robust, Scalable, Maintainable Event Architectures Event-driven architecture (EDA) gives teams the ability to build decoupled, scalable systems that evolve independently. In the previous article, we introduced the idea using a restaurant analogy: instead of shouting instructions across the kitchen, teams place "dockets" on the rail and stations take what they need. We'll continue that analogy lightly in this post--sprinkling it here and there--while focusing on the engineering patterns that make event-driven systems work in practice. Core Patterns in Event-Driven ArchitecturePattern 1: Event Notification An event notification is a tiny message that simply declares "something happened." It doesn't contain all the details--just enough for downstream systems to react. Think of it like a kitchen bell dinging: The bell doesn't contain the meal. It's just a signal. The cook still needs to check the ticket rail (the database) for the details of the order 12345. Example { "eventName": "OrderCreated", "orderId": 12345, "createdAt": "2025-11-26T01:00:00Z" } Why it's useful Extremely lightweight Easy to publish, easy to fan out Consumers decide how much extra data they need Trade-offs Consumers must fetch details themselves More cross-service calls -> more coupling Higher latency when many consumers query upstream systems Use this pattern when the event is a simple trigger--like a bell, not a full meal. Pattern 2: Event-Carried State Transfer (ECST) In Event-Carried State Transfer, the event carries all required data so consumers don't need to make additional calls. It's the equivalent of the chef not only ringing the bell but also placing the complete plated dish on the pass. No one needs to ask questions--everything needed is right there. { "eventName": "OrderPacked", "orderId": 12345, "items": [ { "sku": "ABC123", "qty": 2 } ], "warehouseId": 19, "totalWeightGrams": 1850 } Why it's powerful Zero need for back-calls -> full decoupling Highly resilient--consumers can proces ## Reclaim the reactivity of your state management, say no to imperative MVI DevFeed: [Reclaim the reactivity of your state management, say no to imperative MVI]() Original publisher: [Read original article]() Author: Gabor Varadi Published: 2022-05-02T05:05:46Z Content type: opinion Language: en Sources: [Stories by Gabor Varadi on Medium]() Topics: [reactive](), [Redux](), [Elm](), [JavaScript](), [Programming]() Tags: [android](), [android-app-development](), [androiddev](), [architecture](), [architecture-pattern](), [clean-code](), [elm](), [javascript](), [model-view-intent](), [mvi](), [reactive](), [redux](), [state](), [state-management]() ### AI overview The article critiques imperative MVI-style state management as overly complex and boilerplate-heavy. It traces MVI's web-oriented history through Cycle.js, The Elm Architecture, and Redux, and questions whether those patterns fit statically typed application development. ### Source excerpt Do you find yourself chasing for "clean code, clean architecture, clean design, clean state management" yet still feel bogged down in a sea of boilerplate for even the simplest of tasks -- such as showing a simple list fetched with a coroutine? Surely this could be done in a single line or maybe about seven, but it certainly shouldn't need gigantic case-whens, three layers of indirection, and so on? Well, normally you could just invoke functions on ViewModel and it would work, but if you're forced to seek the "architectural holy grail", no one around you will trust your code unless you add at least one sealed class called ViewActions, and increase the cyclomatic complexity of your "action handler" function until it feels "just clean enough". (After all, surely the more completely unrelated things a single function does based on its argument, the more it has a "single responsibility" of handling literally everything, which is why you know it's definitely the best possible way to do it. 😏) Anyway, the boilerplate of coupling together all aspects into a single class, whether it is a function call or state property, this all has a history: namely, it came from the web. The brief history of MVI MVI stands for "model-view-intent" and comes from a (not very popular for use in production) Javascript framework called Cycle.js, hand-in-hand with a (not popular anymore) concept called "The Elm Architecture" defined as the best practices and intended use of an experimental (and since 2019, unmaintained) "functional-reactive programming language for the web" called ELM. Then again, these didn't come from a vacuum either -- the originator is Redux, in 2015. The general idea was to implement a state machine using the command processor pattern in Javascript, thereby supporting "undo" functionality (also often referred to as "time-travel debugging"). Of course, most design decisions of Redux only make sense for Javascript -- as it is a language with no static typing. It makes sense to ## Choosing an Architecture Pattern for Android Applications DevFeed: [Choosing an Architecture Pattern for Android Applications]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2019-08-16T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Android](), [mvc](), [App](), [Code]() Tags: [android](), [architecture](), [architecture-pattern](), [mvc](), [mvi](), [mvvm](), [patterns]() ### AI overview This tutorial explains why Android applications need architecture patterns and compares approaches including MVC, MVP, MVVM, MVI, and MVU. It emphasizes separating application code into distinct components rather than placing all code in an Activity. ### Source excerpt As an Android developer, one of the questions I constantly see asked within the community is "what architecture pattern should I use?" This discussion usually leads to a handful of buzzwordy acronyms: MVC MVP MVVM MVI MVU?? (We don't talk about this but apparently it's the new kid on the block) This can be really intimidating to new Android devs, as well as seasoned veterans who are constantly questioning if they're using the right one. Whether you're trying to decide which one to learn, or wondering if the one you already use is best for you, this post will help lead you to the right decision. ## Twitch for Android: From Meme to Dream DevFeed: [Twitch for Android: From Meme to Dream]() Original publisher: [Read original article]() Author: Joaquim Verges Published: 2019-02-26T21:45:39Z Content type: article Language: en Sources: [Twitch]() Topics: [Android](), [Mobile](), [test](), [unit test](), [ui](), [Code]() Tags: [android](), [architecture](), [architecture-pattern](), [development](), [engineering](), [mobile](), [test](), [twitch](), [ui](), [unit-test]() ### AI overview Twitch describes how its PogDroid Android app grew from a small app with basic streaming and chat functionality into a larger project. The team redesigned the app, rewrote much of it, introduced a common MVP architecture, and organized code into data, presentation, and view layers to make unit testing easier. ### Source excerpt Meet PogDroid, our beloved Android app, to watch the latest memes unfold live while on the go. PogDroid started with very humble beginnings, and has seen incredible growth in the past couple of years. We quadrupled the team, redesigned the entire app, and rewrote most of it in only a few months using the latest and greatest Android has to offer. Buckle up: this is PogDroid's epic adventure. Level 1: Meme app with big dreams Back in March 2017, PogDroid was maintained by a very small team of engineers, and covered the most basic functionality of Twitch: browse and watch a stream with Chat. Old PogDroid, before the big makeover Mobile, and Android in particular, was getting more and more users, and the company decided it was time for a serious investment in PogDroid. The plan was to give the app a fresh new look, and build up some important features that were missing. The team grew only a little bit, but were tasked to take on this big project. As with most apps maintained by a very small team, the code structure was a mess. It became clear that such a big redesign compounded with adding new features could not be built cleanly on top of the current foundation. There was no common pattern to build screens, not a single unit test, and a lot of core classes were more than 3,000 lines of code long, with very complex state management, handling everything from network requests to UI rendering. We all agreed that in order to make PogDroid what we were dreaming of, we first needed to rethink its foundations. Step 1: Agree on a common architecture pattern The first thing we did is come up with a common design pattern to build features and screens. We wanted this design pattern to be: easy to understand hard to get wrong flexible enough to be applied to any feature or screen easy to unit test We quickly settled on a straightforward MVP pattern that looks like this: With these layers in mind, it became easy to categorize the type of classes we needed for every feature: Typical c ## Perfect is the Enemy of the Good DevFeed: [Perfect is the Enemy of the Good]() Original publisher: [Read original article]() Author: Keegan Rush Published: 2018-11-13T00:00:00Z Content type: opinion Language: en Sources: [The Coded Self]() Topics: [Development](), [Programming](), [Concurrency](), [reactive](), [Dependency injection](), [Mocking](), [App]() Tags: [architecture](), [architecture-pattern](), [async](), [concurrency](), [dependency-injection](), [development](), [dispatchqueue](), [mocking](), [programming](), [queue](), [reactive](), [reactive-programming]() ### AI overview The author reflects on a side project whose elaborate architecture and extensive tooling created hidden complexity, debugging difficulties, and development friction. The article examines the use of RxSwift, VIPER, Swinject, Cuckoo, and Flow Operations in an app and argues that architectural perfection can undermine practical progress. ### Source excerpt How the Wrong Architecture Can Cripple Development A couple of years ago, I was working on a side project with a few friends. We thought that it would be the next big thing. We put our collective best efforts into it; I worked long, hard hours fleshing out the scaffolding of the perfect architecture. Little did I know that my effort would doom the project to join the abyss of failed projects as quickly as it had begun. We had the best tools Since this was The Next Big Thing™, we used everything at our disposal. RxSwift for reactive programming VIPER for our architecture pattern Swinject for dependency injection Cuckoo for mocking Flow Operations for managing navigation The Flow Operations were a particularly interesting concept, inspired by the Advanced NSOperations session from WWDC 2015. We used Flow Operations to manage navigation in the app. For instance, if you wanted to register a new user, you'd invoke a RegisterFlowOperation. A FlowOperation was a subclass of Operation: class FlowOperation: Operation The Operation class represents the code and data for a task of your choosing. It also handles concurrency and dependencies. So, our Flow Operations represented the task of flowing from one screen to another in an app. Operations can be dependent on each other - for instance, the EditProfileFlowOperation is dependent on the SignInFlowOperation. If you've already signed in, you can edit your profile, but if you haven't, then you'll be directed to sign in if you invoke the EditProfileFlowOperation. How does it work? There was a lot of hidden complexity in the Flow Operation system, and some trickiness that you wouldn't notice until you started using it. I'll briefly go over some of the code. You could sell products in this app we were building. This is how you'd start the Sell Flow: private func startSellFlow() { DispatchQueue.global().async { [navController = navController] in let flow = SellFlowOperation(navigationController: navController) flow.beginFlow() flow. ## Building An Application With MVVM DevFeed: [Building An Application With MVVM]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2018-10-28T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Development](), [LineageOS](), [Mobile](), [App]() Tags: [android](), [android-architecture](), [android-development](), [architecture](), [architecture-pattern](), [building](), [patterns]() ### AI overview This tutorial introduces the MVVM architecture pattern for Android application development. It explains the roles of the Model, View, and ViewModel components, including how the ViewModel maintains state, interacts with the data source, and handles relevant business logic. It also compares MVVM's communication flow with MVP. ### Source excerpt This is the second post in what will be an ongoing series to demonstrate a few different architecture patterns that are used for Android development. You can find the code for each of them, often appearing before the blog posts, by following this repo. Give it a star! In our previous post we discussed the MVP architecture for building an app. This time, we're going to check out MVVM. ## Building An Application With MVP DevFeed: [Building An Application With MVP]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2018-10-20T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Android](), [android-development](), [Development](), [ui](), [data](), [Code](), [Server]() Tags: [android](), [android-development](), [architecture](), [architecture-pattern](), [building](), [business-logic](), [code](), [communication](), [component](), [context](), [data](), [development](), [flow](), [repo](), [source]() ### AI overview This tutorial introduces the Model View Presenter (MVP) architecture pattern for Android development. It explains the roles of the model, view, and presenter, and describes how they communicate while keeping the model and view separated. ### Source excerpt This is the first post in what will be an ongoing series to demonstrate a few different architecture patterns that are used for Android development. You can find the code for each of them, often appearing before the blog posts, by following this repo. Give it a star! The first architecture pattern we're going to walk through is MVP. ## Ziggurat iOS App Architecture DevFeed: [Ziggurat iOS App Architecture]() Original publisher: [Read original article]() Author: Square Engineering Published: 2015-12-18T17:10:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [iOS](), [Swift](), [mvc](), [flux](), [React Native]() Tags: [architecture](), [architecture-pattern](), [engineering](), [flux](), [ios](), [mvc](), [react-native](), [swift]() ### AI overview The article introduces Ziggurat, a layered and testable iOS architecture pattern for Swift that uses immutable view models and one-way data flow. It explains how the pattern aims to reduce data complexity and cognitive load, produce smaller classes, and address testing, debugging, and shared-state problems associated with Model-View-Controller. ### Source excerpt Several steps beyond model view controller