Return to Answer

As far as I know, the only reasons for having multiple modules is to satisfy code modularity, attain loose-coupling, and fulfill easy maintenance in the future.

For example, you could have an application module that depends on other modules that implement specific functional areas. These modules are unaware of anything external to themselves and should not care ideally.

Let's say you have a data repository module that includes services and factories that deal with REST APIs of some web service. You could basically reuse this module in multiple applications. It's plug-and-play essentially. Putting all of the services into a separate module that can be dependently injected is just a way to package it up nicely and make it reusable.

Your code example of module use isn't ideal in my opinion, nor would I qualify an IIFE as a module. I'd do something more like this:

angular.module('dataRepo');
// 'dataRepo' implementation left out for brevity

// create a new angular app that depends on the 'dataRepo' module
angular.module('myApp', ['dataRepo']);

Also, here's a good article you could take a look at. Scroll down to the section on grouping modules by functionality.

As far as I know, the only reasons for having multiple modules is to satisfy code modularity, attain loose-coupling, and fulfill easy maintenance in the future.

For example, you could have an application module that depends on other modules that implement specific functional areas. These modules are unaware of anything external to themselves and should not care ideally.

Let's say you have a data repository module that includes services and factories that deal with REST APIs of some web service. You could basically reuse this module in multiple applications. It's plug-and-play essentially. Putting all of the services into a separate module that can be dependently injected is just a way to package it up nicely and make it reusable.

Your code example of module use isn't ideal in my opinion, nor would I qualify an IIFE as a module. I'd do something more like this:

angular.module('dataRepo', []);
// 'dataRepo' implementation left out for brevity

// create a new angular app that depends on the 'dataRepo' module
angular.module('myApp', ['dataRepo']);

Also, here's a good article you could take a look at. Scroll down to the section on grouping modules by functionality.

As far as I know, the only reasons for having multiple modules is to satisfy code modularity, attain loose-coupling, and fulfill easy maintenance in the future.

For example, you could have an application module that depends on other modules that implement specific functional areas. These modules are unaware of anything external to themselves and should not care ideally.

Let's say you have a data repository module that includes services and factories that deal with REST APIs of some web service. You could basically reuse this module in multiple applications. It's plug-and-play essentially. Putting all of the services into a separate module that can be dependently injected is just a way to package it up nicely and make it reusable.

As far as I know, the only reasons for having multiple modules is to satisfy code modularity, attain loose-coupling, and fulfill easy maintenance in the future.

For example, you could have an application module that depends on other modules that implement specific functional areas. These modules are unaware of anything external to themselves and should not care ideally.

Let's say you have a data repository module that includes services and factories that deal with REST APIs of some web service. You could basically reuse this module in multiple applications. It's plug-and-play essentially. Putting all of the services into a separate module that can be dependently injected is just a way to package it up nicely and make it reusable.

Your code example of module use isn't ideal in my opinion, nor would I qualify an IIFE as a module. I'd do something more like this:

angular.module('dataRepo');
// 'dataRepo' implementation left out for brevity

// create a new angular app that depends on the 'dataRepo' module
angular.module('myApp', ['dataRepo']);

Also, here's a good article you could take a look at. Scroll down to the section on grouping modules by functionality.

As far as I know, the only reasons for having multiple modules is to satisfy code modularity, attain loose-coupling, and fulfill easy maintenance in the future.

For example, you could have an application module that depends on other modules that implement specific functional areas. These modules are unaware of anything external to themselves and should not care ideally.

Let's say you have a data repository module that includes services and factories that deal with REST APIs of some web service. You could basically reuse this module in multiple applications. It's plug-and-play essentially. Putting all of the services into a separate module that can be dependently injected is just a way to package it up nicely and make is reusable.

As far as I know, the only reasons for having multiple modules is to satisfy code modularity, attain loose-coupling, and fulfill easy maintenance in the future.

For example, you could have an application module that depends on other modules that implement specific functional areas. These modules are unaware of anything external to themselves and should not care ideally.

Let's say you have a data repository module that includes services and factories that deal with REST APIs of some web service. You could basically reuse this module in multiple applications. It's plug-and-play essentially. Putting all of the services into a separate module that can be dependently injected is just a way to package it up nicely and make it reusable.