1.4 Modules, Marketplace Content & Module Boundaries
Key Takeaways
- A Mendix app is a container of modules; each module owns exactly one domain model plus its own pages, logic, resources, and module roles, which is why every entity is addressed as ModuleName.EntityName.
- Studio Pro distinguishes app modules, add-on modules, and solution modules, and add-on and solution documents carry an Export level of Hidden (default) or Usable that controls what a consumer can see.
- End users are assigned user roles in app security, and app security maps those user roles onto the module roles defined inside each module — module roles are never assigned to users directly.
- Marketplace modules should be treated as read-only: local edits are overwritten by the next update, so extend them from a separate wrapper module instead.
- Updating a Marketplace module does not always remove the old JAR from userlib, which causes classpath conflicts; from Mendix 10.3.0 platform-supported modules increasingly ship Java dependencies through Managed Dependencies instead.
1.4 Modules, Marketplace Content & Module Boundaries
Exam Focus: "Modules" is one of the eight scored sections of the Intermediate Developer exam, and it is the section candidates most often under-prepare because it feels like plumbing. You need to know what a module actually contains, how module security relates to app security, how Marketplace content is imported and updated, what happens to Java dependencies during an update, and where the boundary between two modules should sit.
What a Module Is
A Mendix app is a container of modules. The app level owns everything global — navigation profiles, app (project) security, languages, the theme, and app-wide settings — while each module owns a self-contained slice of functionality.
| Module element | What it holds |
|---|---|
| Domain model | Entities, attributes, associations, and entity access rules — exactly one domain model per module |
| Pages & page resources | Page documents, layouts, menus, snippets, building blocks, page templates |
| Logic | Microflows, nanoflows, rules, and (where present) Java actions |
| Integration | Consumed and published REST/web services, import and export mappings, message definitions, JSON and XML schemas |
| Resources | Constants, enumerations, datasets, scheduled events, images, documents |
| Security | Module roles, and their access settings for entities, pages, microflows, and datasets |
Because each module carries its own domain model, an entity's fully qualified name is always ModuleName.EntityName. That is exactly why XPath paths, import mappings, and access rules always carry a module prefix — Sales.Order_Customer/Sales.Customer/City names the module twice for a reason.
Three Module Types
Studio Pro distinguishes:
- App modules — the standard, default module type inside your own app.
- Add-on modules — modules built for distribution to other apps.
- Solution modules — modules that form part of a packaged solution offering.
Documents inside add-on modules and solutions carry an Export level that governs what a consumer of the module can see and use: Hidden (default) keeps the document's content invisible to the consumer, while Usable lets the consumer see it in their app and use it. Getting the export level right is the difference between shipping a clean module API and leaking your internals.
Module Security vs. App Security
Mendix deliberately splits security into two tiers, and the exam tests the direction of the mapping:
- App (project) security defines user roles — the roles a real end user is assigned.
- Module security defines module roles — capability sets that only make sense inside one module.
- App security then maps each user role onto zero or more module roles, across any number of modules.
Users are never assigned module roles directly. That indirection is precisely what lets you import a Marketplace module carrying its own Administrator and User module roles and wire them into your existing Employee and Manager user roles without touching the module's internals. The full role-mapping mechanics are covered in Section 6.1.
Exam Trap: An answer that says "assign the module role directly to the end user" is always wrong. So is "the module's entity access rules apply automatically to every user role" — nothing applies until you map a user role to that module role.
Importing and Updating Marketplace Content
Mendix classifies Marketplace content by who maintains it: platform-supported content is maintained by Mendix itself, while community-supported content is maintained by its author. That distinction should drive whether a module belongs in a production build, and it is worth checking before you commit an integration to it.
Content arrives in several shapes — modules, pluggable widgets, connectors, solutions, and sample apps — and importing a module drops it into your app as an ordinary module in the App Explorer.
The rules that matter in practice:
- Treat a Marketplace module as read-only. Updating it replaces its documents. Any microflow you edited inside it, any attribute you added to its domain model, is gone on the next update. When you need different behaviour, build a thin wrapper module of your own that calls into it.
- Check the Errors pane immediately after import. Missing dependency modules — Atlas Core, Data Widgets, Community Commons — are the usual cause of a wall of red after an otherwise successful import.
- Watch
userlib/on every update. Older versions of a dependent JAR are not always deleted when a module is updated, and two versions of the same library on the classpath produce runtime failures such asNoSuchMethodError. Delete the obsolete JAR by hand. From Mendix 10.3.0 onward, platform-supported modules increasingly obtain their Java dependencies through Managed Dependencies rather than loose JARs inuserlib/, which removes most of this class of problem — but not for older or community modules. - Read the module's configuration steps. Most non-trivial modules need three things wired up: a module role granted to your user roles, a constant configured, and a startup microflow added to the app's after-startup microflow.
Exporting Your Own Module
Right-click a module in the App Explorer and export it as a module package (.mpk) to share it between apps. Before you do, decide the export levels of its documents, check that it does not depend on entities living in a different module, and confirm that it does not use association storage or platform features unavailable in the consuming app's Mendix version.
Where to Draw Module Boundaries
A module boundary is an architectural decision, and the exam frames it as a maintainability question:
| Principle | What it looks like in Studio Pro |
|---|---|
| One module, one capability | Sales, Invoicing, and CustomerPortal — not one MyFirstModule holding everything |
| Expose logic, not tables | Other modules call your SUB_/ACT_ microflows rather than retrieving your entities directly |
| Minimise cross-module associations | Every cross-module association welds two modules together and blocks reuse of either one |
| Never edit Marketplace internals | Extend from your own module; the next update overwrites anything you changed |
| Name for the domain | Module names appear in every entity path, XPath constraint, and log line — vague names cost you daily |
A useful test: could you export this module as an .mpk and drop it into a different app? If the answer is "not without dragging three other modules along", the boundary is in the wrong place.
Practical Exam Scenarios
Scenario 1 — The vanished customisation. A developer adds a validation microflow inside an imported Marketplace module. Six weeks later a teammate updates the module from the Marketplace and the validation silently disappears. The fix is architectural, not procedural: the validation belonged in a wrapper module that calls the Marketplace module, never inside it.
Scenario 2 — The user who can see nothing. A team imports a document-management module, assigns its pages to navigation, and grants the Employee user role access to those pages. Users can open the page but every grid is empty. The module's entity access rules are defined for its module roles, and no user role has been mapped to them yet — the fix is in app security, not in the module.
Scenario 3 — The library collision. After updating a connector, the app fails to start locally with a NoSuchMethodError. Two versions of the same third-party JAR are sitting in userlib/; deleting the obsolete one restores the build.
A Mendix app imports a Marketplace module that defines its own Administrator and User module roles. How do end users obtain the permissions those module roles carry?
A developer edits a microflow inside an imported Marketplace module to add company-specific validation. What is the predictable consequence, and what should have been done instead?
After updating a connector module from the Marketplace, an app fails to start locally with a NoSuchMethodError raised from a third-party library. What is the most likely cause?