Building a Decoupled Architecture to Optimize our Mobile Apps
How did we optimize the mobile apps for the Walmart Mexico market?
In this article, we explain the engineering we applied to standardize and decouple the architecture of these four Walmart Mexico apps:
- Walmart Groceries
- Walmart Plus
- Superama
- Bodega Aurrera
To execute this re-architecture project, the Walmart Mexico E-commerce department put together the multidisciplinary Core Mobile team, responsible for designing and testing the new implementations. Then, the rest of the mobile teams were able to replicate the solutions.
In the beginning, the main goal was the re-architecture, but it evolved to cover other transformations such as CI/CD, test automation, repository strategy, among others.
What Was the Cost of Having a Legacy Architecture?
Given that the different mobile apps share similar user flows, features, and use cases, the project aimed to build a common base for the architecture, the code pieces, and the pipeline of all the apps. This was to avoid different teams redoing the same work as with the legacy architecture.
Before, the developers were redoing 95%-similar pieces of the frontend for the iOS and Android apps. It was practically eight teams working on eight different apps but solving the same problem.
Some pain points we experienced with the legacy architecture are:
- Hardness to reuse code
- Difficulties in scaling apps
- Complex control of code dependencies
- Low quality and inconsistency of the codebase
- Incomprehension of the codebase
- Static teams
How Did the Legacy Architecture Work?
The legacy architecture supported many different versions for iOS and Android mobile apps. For iOS, for example, we had three architectures supporting the four apps. Whereas for Android, we had one architecture.
One of the legacy architecture’s pain points was that some of its layers were built together, which made it hard to reuse the pieces of code as stand-alone modules across the apps.
The following diagram is an example of one of the architecture versions we had. It shows how the layers interacted in the Walmart Plus app.
The previous diagram shows how the four layers existed together and were dependent on each other. The rest of the versions of the legacy architecture had similar implementations and shared the same difficulties.
How Did We Build the New Decoupled Architecture?
The Core Mobile team had the main goal of re-architecting the four mobile apps launched by Walmart Mexico. The mission was to develop a common architecture for all the iOS apps, as well as a common architecture for all the Android apps.
Under this new model, the apps share the same iOS or Android architecture. However, they are still different from each other because they have their own implementation of the components within the layers. This is possible given that the new architecture is decoupled and divided into modules. For this reason, the same components and layers present a different implementation, according to the module they belong to.
In this project, we call the modules Contexts. They set the limit of a specific part of Walmart’s business and, at the same time, they contain all the architectural components necessary to execute one functionality of the apps.
The functionality relates to the part of the business that the Context delimits itself. Checkout and Sign In are examples of Contexts within the mobile apps. In these cases, the Use Case layer, which is common across the apps, might present a different implementation if the Context is Checkout or Sign In.
The following diagram illustrates how the modules, layers, and components interact in the decoupled architecture.
From the previous diagram, you can see that Contexts contain Subcontexts, each belonging to a specific app. The Subcontext contains the different layers of Presentation, Business Logic, and APIs that interact to make up the functionality of the Context they belong to.
There might be cases where the Subcontext is optional because the business logic and the API gateway are the same across all the apps. In these cases, the entire module can be reused.
How Did We Leverage DDD, Clean Code, and MVVM?
To achieve a standardized and decoupled architecture, we followed these guidelines of software development:
- Domain-Driven Design (DDD): Proposes that the core of the architecture must be the Domain Layer, including all the business logic. In the Walmart apps, Contexts are the core of the modularization, which relate to Walmart’s business activities.
- Model, View, ViewModel (MVVM): Proposes that the user interface (UI) must be separated from the business logic.
- Clean Architecture Model: Proposes that the software must be separated in layers, following the rule of dependencies pointing inwards.
The following illustration shows the Dependency Rule in the Clean Architecture Model. To see this image from its original source, visit The Clean Code Blog.
What Is the Impact of the New Architecture?
After implementing the new decoupled architecture, we have identified not only technical benefits in the apps but also cultural benefits in the teams.
Some of the technical benefits of implementing the decoupled architecture are:
- Developing faster and more reliable code.
- Reusing code through modules (when applicable).
- Scaling apps easily.
- Controlling dependencies at a fine-grained level.
- Improving the ownership and the quality of the codebase.
Whereas some of the cultural benefits of implementing the decoupled architecture are:
- Working interchangeably across teams.
- Reducing time and resources by avoiding replicated work.
- Empowering better-focused teams.
What Challenges Have We Faced?
In the path of implementing all the changes that come along with the new architecture, we have faced some challenges such as:
- Lack of full-time developers: As we work on the re-architecture, we are also attending the business and working on the requirements from the mobile apps that are already in the market.
- Learning Curve: Implementing the new architecture, the new software development models, and the rest of transformations have required an extra effort from the developers to acquire the knowledge.
- Adding Sam’s on-board: The Sam’s mobile app is still working with the legacy code. We will include it in the new architecture in future phases.
What Other Transformations Did We Have?
The impact of the new architecture also reflects in other transformations that the Walmart Mexico mobile team was able to execute, for example:
- Implementation of Walmart One: We developed a single frontend for both Walmart Groceries and Walmart Plus backends.
- Implementation of CI/CD: We set-up the CI/CD pipeline for the apps leveraging Looper, the server developed on top of Jenkins by the Walmart Labs team.
- Implementation of QA Automation: We put together a team to transform our Quality Assurance (QA) effort by building an automated testing strategy.
- Implementation of monorepo: We changed our repository strategy from multirepo to monorepo, in order to get an easier workflow for all teams.
- Implementation of trunk-based development: We transformed our version-control branching model to improve collaboration, versioning, and delivery.
- Implementation of full-documentation: We started the practice of documenting each transformation, which made it easier to replicate.
This text was written by Alejandra Pedroza on behalf of Migcenel González, Miguel Pahua, Alan Cruz, Abdiel Soto, Daniel Reyes, Juan Pablo Villa, and the Core Mobile Team.
