There's a popular adage in software design called Conway's Law, which suggests that the design of software in any organization is influenced by the structure of teams in the organization and the way they communicate with each other. It makes perfect sense if you think about it. Software development teams often tend to work on isolated libraries and code bases (or at least, code areas) that talk to other libraries and code bases developed by other teams. In a sense, there's almost a one-to-one mapping between teams and the set of code assets they work on. This can be a valuable factor that influences where module boundaries are drawn and how modules designs begin to separate from one another. Each team works on one or more modules, and so all the code that a given team would work on becomes a part of their set of modules.

This is useful for a variety of reasons. Teams can work on their code and ship out functionality independent of other teams. They are assigned ownership of modules, so they can handle bug fixes or code maintenance. Additionally, when starting out a new project, when two teams need to work on modules where one depends on the other, both teams can together come up with an API contract that they agree with. Then, each team can work on their modules separately and in parallel, although the dependent modules are not yet available.