Angular Module Organization/Architecture

Question

Having worked with angular for a while now, I am now seeing people break a single application out into multiple modules and I am debating the merits of such an approach.

Single Module

angular.module('myApp', []);
angular.module('myApp').controller('FooCtrl', function(){});
angular.module('myApp').service('foo', function(){});
angular.module('myApp').directive('fooElement', function(){});

Multiple Modules

angular.module('myApp.Controllers', []);
angular.module('myApp.Controllers').controller('FooCtrl', function(){});
angular.module('myApp.Services', []);
angular.module('myApp.Services').service('foo', function(){});
angular.module('myApp.Directives');
angular.module('myApp.Directives').directive('fooElement', function(){});

// Then inject the separate modules into the "parent" module
angular.module('myApp', [
    'myApp.Controllers',
    'myApp.Services',
    'myApp.Directives']);

I am all for modularity, but these separate modules are so specific that they are not going to get any reuse outside of the app in which they are created that they will not be re-used for any other purpose (read: not injected into any other module).

So what is the point that one would decide to separate your app which is defined as a singular module into multiple modules when reuse outside is not a valid concern?

Answer 1

Generally speaking

The same question could be asked for any platform that has modular application development. Why seperate a .NET application into separate assemblies if all of the code is only used in one place?

1. It allows versioning of blocks of functionality.
2. It allows re-use/sharing of blocks of functionality between other applications.
3. It provides clearer separation between blocks of functionality.

In Angular, specifically

In Angular, too, there's some merit to the idea that not all of your application's functionality needs to be in the same Single Page Application. For instance, not every user of your application might need to load user management code when they're loading the main app. So you could separate that out into a different SPA. But that new SPA might need to share API access code or UI elements, so those things could be encapsulated in Modules.

Likewise, UI elements (directives) are things that could be highly sharable between completely different applications throughout an organization. So those things could be in their own module(s), for just that purpose.

Answer 2

There are many circumstances where organizing and/or breaking the typical angular module into separate modules makes perfect sense; it makes the app easier to maintain, and it makes the app code more accessible and more easily distributed.

For instance, if you look at the approach taken here, you can get a better picture of how an angular application can be written and organized more prototypally, with controllers deriving from basecontroller and so forth.

As to why you would break every angular provider type into its own module, I cannot say. It doesn't seem to favor many principles of good design, nor does organizing modules per-provider-type offer much benefit to the app or the developer. It kinda seems like one of those silly things that everyone sees in some answer on SO, then catches on, and begins to crop up in blog posts everywhere (not unlike the imaginary useXDomain flag on $http).

Advocating it, the best argument I can think of is - it could give you a per-provider-type testing orthogonality.