Modules are singletons that are instantiated automatically by the Framework when access is explicitly requested in executing code, or when the Module becomes "relevant" due to a context shift. Modules have program elements that are explicitly declared as such; these elements include: Ribbon Buttons, Tools, Galleries, Combo Boxes, Edit Boxes, Palettes, and other controls, as well as application Panes and Docking Panes. The well-defined relationship between a Module and its associated components lets the application initialize, un-initialize, and remove entire subsystems as a whole.

Modules act as the hub and central access point for their subsystem; if you need access to the functionality within a subsystem, you start with the Module. By convention, all public properties and methods on Modules should be static; clients can reference the associated assembly and then directly use the Module class without having to call Find (or pass the Module ID).

Most of the logic in a sub system should reside in a module or a helper (non-UI) class the module directly manages. For example, when writing a button, the Button class itself should have no business logic in it; all the logic should be centralized in its parent module. Centralizing the business logic reduces the spaghetti-effect. For example, instead of several buttons each listening to a particular event, it’s better to have one Module listen to the event and each Button instead polls the Module in OnUpdate.

Modules support several patterns to make centralizing business logic much easier; for instance, modules automatically load whenever one of their plug-ins (program elements) load. For example, in most cases a button on the ribbon doesn’t load until it is clicked; when this happens, the button’s parent Module is also loaded. Similarly, when a dock pane loads, its parent Module also loads.

Modules also have a pattern for working with Panes. Modules are automatically notified whenever one of its panes are activated, deactivated, opened, or closed. This means a Module doesn’t have to listen to the Framework’s ActivePaneChanged event and from here filter for its panes; instead, Modules are given direct notification that one of their panes changed.

Declaring Modules in DAML:

DAML attributes: id Required identifier. caption The name of the Module. description A description of the Module. autoLoad Controls whether the Module loads just-in-time (JIT), the default, or automatically at startup. className Required class identifier. Optionally include namespace if not in default namespace. assembly Assembly name if not in the default assembly. publicKeyToken The necessary public key token if the assembly is strongly named. version The version of the dll if the assembly is strongly named.

System.Object
   ArcGIS.Desktop.Framework.Contracts.PropertyChangedBase
      ArcGIS.Desktop.Framework.Contracts.Module
         ArcGIS.Desktop.Core.CoreModule
         ArcGIS.Desktop.DataReviewer.DataReviewerModule
         ArcGIS.Desktop.GeoProcessing.GeoprocessingModule
         ArcGIS.Desktop.Reports.ReportsModule
         ArcGIS.Desktop.TaskAssistant.TaskAssistantModule
         ArcGIS.Desktop.Workflow.WorkflowModule

Target Platforms: Windows 10, Windows 8.1

Reference

Module Members
ArcGIS.Desktop.Framework.Contracts Namespace