1.4 Modules, Marketplace Content & Module Boundaries

Mendix Certified Intermediate Developer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Blueprint, Agile Collaboration & Project Structure

1.1 Exam Blueprint, Format & Logistics 1.2 Mendix Project Lifecycle & Agile Roles 1.3 Project Directory Structure & Architecture 1.4 Modules, Marketplace Content & Module Boundaries 1.5 Team Server, Branching & Version Control

2 Chapter 2: Advanced Domain Modeling & Entity Architecture

2.1 Persistable vs. Non-Persistable Entities 2.2 Entity Generalization & Specialization 2.3 Associations & Delete Behavior 2.4 System Members, Attributes & Indexing

3 Chapter 3: XPath Constraints & Data Retrieval

3.1 XPath Syntax & Association Traversal 3.2 XPath Functions, System Tokens & Date Math 3.3 Advanced Filtering Patterns & Database Performance

4 Chapter 4: Advanced Microflows & Business Logic

4.1 Sub-microflows & Modular Architecture 4.2 List Operations & Aggregations 4.3 Loops, Batch Processing & Rules 4.4 Error Handling & Transaction Management 4.5 Client Notifications & User Feedback Activities

5 Chapter 5: Advanced UI, Navigation & Atlas UI

5.1 Atlas UI Architecture & Design System 5.2 Advanced Widgets, Snippets & Building Blocks 5.3 Dynamic Behavior: Conditional Visibility & Editability 5.4 Multi-Language & Internationalization

6 Chapter 6: Application Security & Access Control

6.1 Security Architecture & Security Levels 6.2 Entity Access Rules & Attribute-Level Security 6.3 Row-Level Security via XPath Constraints 6.4 Anonymous Users & Public Access

7 Chapter 7: REST & SOAP Integrations

7.1 Consuming REST Services 7.2 Import & Export Mappings with JSON & XML 7.3 Publishing REST Services 7.4 Consumed SOAP Web Services & Error Handling

8 Chapter 8: Mobile Development & Nanoflows

8.1 Mobile Architectures: PWA vs. Native Mobile 8.2 Nanoflows Architecture & Client-Side Execution 8.3 Offline Synchronization & Conflict Resolution

9 Chapter 9: Debugging, Quality Assurance & Operations

9.1 Microflow Debugger & Diagnostic Tools 9.2 Logging, Error Tracking & Monitoring 9.3 Consistency Checks, Best Practices & Quality

1.4 Modules, Marketplace Content & Module Boundaries

Key Takeaways Explain This Topic AI

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.

Last updated: September 2026

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 as NoSuchMethodError . 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 in userlib/ , 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.