Angular folk are often quick to point out that "Angular isn't a framework; it's an HTML compiler", or, as their homepage states, "AngularJS is a toolset for building the framework most suited to your application development." Angular doesn't necessarily set out to solve all of the problems and use cases that developers might run into, but rather Angular intends to give you all of the proper data-binding, dependency injection, and testability primitives as a foundation to build your app upon.

Because it doesn't intend to solve all the problems that a framework might, Angular is far fewer conventions about how to organize large-scale applications than a much heavier and opinionated framework like Ember. This doesn't mean Angular doesn't scale, or that it can't be used to build large apps, but it does explain why it's common for different teams to build large Angular apps in totally different ways, using different patterns, etc.

Ember on the other hand sets out to establish way more conventions, built right into the framework, for solving problems common to most web apps. These patterns are rigorously battle-tested since everyone is using them, and as such, it's easy (once you're past the learning curve), to drop into someone else's Ember app and know exactly where to go to diagnose a problem. That being said, when these patterns aren't helpful for an app's specific needs, most of Ember's patterns/abstractions are, like Angular, built upon composable primitives that you can use to assemble your own data structures, custom classes, etc., to tailor to your app's needs.