This post has been republished via RSS; it originally appeared at: Microsoft Mobile Engineering - Medium.
Scaling Teams Mobile Development — The Mental Model
In the article Scaling Teams Mobile Development — Evolving the design pattern we explored how multiple partner teams working on a large code base can be streamlined by employing the contributor design pattern. I decided to write this article as a prequel. In this article we will discuss the problem statement in a more generic way and draw some parallels with popular design patterns.
We started with the following mission statement in mind:
Make partner integrations with Teams mobile easier, well segregated, with clear protocols.
Teams is a complex mobile application with a LOT of integration points. Partner teams surface their features through these entry points. The following image highlight few entry points available in Teams.
When we looked at the partner integration story in Teams codebase, it became evident that the whole integration story is a Producer-Consumer design pattern which is not implemented correctly.
Here is the mental model that we built: Entry points are consumers of features and partner teams are producers of features. In the existing method, each partner team directly integrated with the entry point. This meant each consumer had to know the producers directly and when a new producer was added, the consumer had to be updated. This resulted in tight coupling. This is not a scalable model.
For the system to scale we need to decouple the producers and the consumers and build strong contracts between them. We wanted to safeguard changes to the consumer. At the same time, we wanted to make the producers independent and able to churn out their features fast. We also wanted to centralize control on producers and its features for deciding their ordering, filtering, enablement etc.
So, we evolved this design pattern, where we define multiple Feature interfaces which will serve as a contacts between the producer and the consumer. It will abstract and codify all aspects of communication between the producers & a consumer. A producer may implement one or many Features. A consumer always supports one type Feature. We built a Registry where the producers will register. We built a Manager which the consumers can query.
To explain the flow: A consumer will ask the manager for features of a specific type that it is interested in. The manager will ask the registry for all the producers which support that feature type. Then manager internally obtain features from all the producers, sort and filter them before returning to the consumer.
With this we ended up with a system where:
- Producers are implemented in isolation in their own modules.
- Producer registers themselves in a central registry.
- Consumers consume the Features from the Producers through the Manager.
- Ordering, filtering, monitoring of Producers and their Features are centralized in the Manager.
- Consumers are safeguarded. Producers doesn’t even know about Consumers.
When we applied this design pattern to Teams code base, we came up with the contributor design pattern terminology, where:
- Site is the Consumer.
- Contributor is the Producer
- Contribution is the Feature.
- ContributorRegistry became the Producer Registry.
- ContributionManager became the Feature Manager.
Design patterns are commonly used solutions to recurring problems in software design. The classical Producer-Consumer design pattern is typically associated with a highly concurrent system. Contributor design pattern is a specific adaptation of this in a practical scenario where there is contention between multiple partner teams working on the same codebase as a means to streamline them.
Scaling Teams Mobile Development — The Mental Model was originally published in Microsoft Mobile Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.