We started by describing, in a general way, how a Backbone application works. It describes two main parts: a root application and subapplications. The root application provides a common infrastructure to other smaller and focused applications that we call subapplications.

Subapplications should be loose coupled with other subapplications and should own its resources such as views, controllers, routers, and so on. A subapplication manages a small part of the system with a well-focused business value and the communication between subapplications and infrastructure application is made through an events-driven bus with Backbone.Events.

The user interacts with the application using views that a subapplication renders. A subapplication controller orchestrates interaction between views, models, and collections and owns the business logic for the use case.

Finally, a file system organization explains the right sites to put your files and keep your project clean and organized. This organization does not follow an MVC pattern; however, it is powerful and simple. It encapsulates all the necessary code for a module in a single path (subapplication paths) instead of putting all the code across multiple paths.

In this way the structure of Backbone applications has been proven to be robust, a proof for this is that several open source applications such as TodoMVC follow (more or less) the principles exposed here. It facilitates the testability of the code due to separation of responsibilities so that each object can be tested separately.

Large Backbone applications are often built on top of Backbone Marionette as it reduces the boilerplate code; however, Marionette uses its own conventions to work. If you are fine with it using its own conventions, you will be happy to use Marionette on top of Backbone.

However, if you love the freedom of doing things your way, you may prefer plain Backbone and create your own utilities and classes.

In the next chapter, I will show you how to manage and organize views and simplify the complex layouts, identifying the common uses of the views. You will build general purpose views that will be useful for all your projects and forget about the implementation of the render() method.