# Problem Overview The current aging MVC architecture in `patch-hub` has grown increasingly fragile as new features have been added. The most critical architectural issue is that the system is evolving into a "big ball of mud" pattern where components become tightly coupled and responsibilities become blurred across the codebase. The App struct serves as a central state manager that is becoming increasingly complex. This struct manages numerous responsibilities including screen state, API clients, configuration, logging, and various data collections, indicating a violation of the single responsibility principle at the architectural level. These problems make it harder to maintain and test components. # Proposed Solution The new architecture will have five components: - The event handler - App - Model - Viewmodels - View The two new characters are `Viewmodel`s and `View`s. These two traits will be used to separate the UI from the logic concerning the UI (while the `Model` stores the overall business logic and data). To put it simply, a `Viewmodel` is responsible for processing actions (such as add bookmark or send mail) that the user takes in the `View` (which is essentially just the UI). The `App` will be the first and foremost struct initialized, holding general configuration and information about the app itself, such as the current screen, a collection of viewmodels and views. `App` will also be responsible for drawing the screen/view. After initializing and drawing the first screen, the event handler takes over. Any event is sent to the corresponding ViewModel for the screen (matched with the `CurrentScreen` field in `App`). As always, if I left anything out or if anyone has any suggestions, please let me know!