SDD - Squad Driven Design

Working in multiple big teams I've found that we are always trying to apply our known best practices in software, but we always reach this point where there is a bottle neck in our code base related to multiple squads working together ... lately I've seen the same pattern repeating over again and again, for the last 3 companies that I've worked in to, they were inspired by the "spotify model" and they started with it and then tried to invent there own variation of it, specially when it comes to Mobile Project Architecture and how to reflect the Squad's into code base

So I'm trying to share the conclusion that we have come to when it comes to big Android projects owned by multiple squads

And since our main concern was to apply best practices to deliver the business value in a Squad based teams, I believe this approach should be oriented about how we design our software when we have multiple squads are involved, or in other words ... Squad Driven Design

The Objective of SDD

• Separation of Concern
• Clear Squad Ownership
• Avoiding Inter-dependecies & Circular dependencies
• Minimum Code Review required (only required in Application level)

Architecture Levels

In this Architecture our project is divided into 4 levels (or groups), each one of them abide to certain rules ... and for each squad they follow these rules based on what level (or group) they are implementing there code in to

Application Level

At this level, only the Application module belongs to it, and the rules that should be follows in this level are

• Application module can see all other 3 levels (it depends on all of the code that sits in those other 3 levels)
• Navigation logic and dependency injection is executed in this level, as for each squad after finishing there work in there own feature module, and merging there code, they go apply the navigation logic, and any dependency injection related logic that connects between multiple squads in this level (which shuold be very rare using frameworks like Hilt), and this becomes the last step (or PR) before activating a feature in the application
• This is the only level that has a shared ownership between all squads, and making any change in this level requires approval from multiple squads
• As long as the navigation logic is not updated for newly added features, squads can work freely on those features and merge them while they are in-progress, since they are not accessible by the user still

Implementations Level

This is the second Level in the Architecture, and in this Level Squads focus on putting there implementations (most day to day work), the rules that should be followed in this level are

• The Application level can access all the code in this level
• This level can access all the code in the levels below, but not the Application level
• The modules / features / SDKs of this level CANNOT interact with each other, which means that there is no inter-dependencies between any code in this level
• Squads have the freedom to choose what ever Architecture for there implementations, as for one squad can use Clean Architecture, other squad can use Layered Architecture, this is an internal matter for the squad
• Squads do implement there requirements code in the modules of this level, but if they require any thing from another Squad, they have to depend on there API code declared on the 3rd level, and use it
• Squads who implement first party libraries to be used by other squads, like analytics or common data-sources ... if these implementations do have any dependencies, they must be implemented in this level, and there API interfaces will be declared in the 3rd level, to be used by other squads

APIs Level

As Squad's modules do not interact with each other on the Implementation level, Squads declare API modules in this APIs level so that they can interact with each other, the rules that should be followed in this level are

• All code in this level is just interfaces and data types, no implementation logic code shuold exist in this level
• All modules in this level should be plain kotlin modules with no dependencies at all
• When ever a squad wants to expose part of it's code, it should declare an interface with it's own new data types in this level, and then implement these interfaces in the implementation level (remember the implementation level depends on the APIs level)
• When ever a squad wants to interact with another squad, they depend on that other squad interfaces, and use it from there own implementation
• Using framework like Hilt can automate big part of injecting implementations, for example, if squad A depends on API interface of squad B, squad B will create the implementation class in there implementation level module, and create Hilt binding between the interface and the implementation in there implementation level "dependency injection" package, so once squad A declares that it is using Squad B API interface, Hilt will handle injecting the implemetation class, and this is one of many ways

• Squads who implemeng first party libraries to be used by other squads, but they are Pure Modules, which means that they do not have any dependencies (like common domain modules), they can be declared in the API level as well ... as long as these are pure modules, which means that they do not have any dependencies of any kind ... and these kinds of modules must be very restrictive and never add any dependency to them, weather they are internal dependnecy or 3rd party ... they must be pure kotlin code

Dependencies Level

And this level is simply the dependnecies declared in the dependencies catalog, weather these dependencies are native libraries like kotlin version, or 3rd party libraries like networking libraries ... but there is no lines of code created by any squad in this level ... it is limited to external code that is not maintained by any squad

As we have gone through the concept of Squad Driven Design, this is a simple examlpe for a multi squad project, showing the critical points of this architecture

Application Level

@HiltAndroidApp
class MyApp : Application() {
    // ...
}

@AndroidEntryPoint
class MainActivity: AppCompatActivity(){
    // handle navigation here between squad's composables or fragments, 
    // or even Activities
}        

Implementations Level

Squad one module

@Module
@InstallIn(SingletonComponent::class)
interface SquadOneModule{
    @Binds
    fun bindSquadOneApi(impl: SquadOneImpl): SquadOneApi
    //...
}

class SquadOneImpl(val squadTwoApi: SquadTwoApi) : SquadOneApi {
    //...
}        

Squad two module

@Module
@InstallIn(SingletonComponent::class)
interface SquadTwoModule{
    @Binds
    fun bindSquadTwoApi(impl: SquadTwoImpl): SquadTwoApi
    //...
}

class SquadTwoImpl(val squadOneApi: SquadOneApi) : SquadTwoApi {
    // ...
}        

APIs Level

Squad one API module

interface SquadOneApi {
    // ...
}        

Squad two API module

interface SquadTwoApi {
    // ...
}        

The focus in the above exampes is how squads do integrate with each other, without depending on each other's implementations

For simplicity we assumed that each squad has one implementation class and one API interface, but in reality the squad will have a whole sub-project and provide the implementation classes only when they declare APIs

There is much more to SDD than the mentioned above, and what ever is not mentioned here can be implemented differently from team to team, but I hope that this gives a hint about this approach generic application in most of the teams