Domain Project and shared resource in Mulesoft

Overview

As your MuleSoft applications grow, you’ll quickly notice one big challenge — reusing the same configurations across multiple projects. Each Mule app might need its own HTTP Listener, Database connection, or Error handling setup. At first, this seems easy… until you have several APIs running on the same Mule runtime.

Let’s look at a common situation.

Imagine you have two Mule projects:

  • CustomerAPI – manages customer information

  • OrderAPI – handles orders and payments

Both start with an HTTP Listener that defines a port number. You might think of setting both to port 8081.
But here’s the catch , a Mule runtime can’t run two apps on the same port. If you try, one of them will fail to deploy.

Now imagine doing this for 10 or more APIs. Constantly managing ports, database credentials, or shared settings separately can become a real headache, time-consuming, error-prone, and hard to maintain.

This is exactly where MuleSoft Domain Projects and Shared Resources come to the rescue.

What Is a Domain Project?

A Domain Project acts as a central hub where you can define resources that multiple Mule applications can share. Instead of repeating the same configuration in every project, you define it once in the domain, and all the related Mule apps simply reference it.

Think of it like setting up a shared Wi-Fi network in your office. You don’t want every employee to set up their own router; instead, you have one network that everyone connects to. The Domain Project works the same way for your Mule applications.

Real-Life Example

Suppose your company runs several Mule APIs:

  • api.shopconnect.com/customers

  • api.shopconnect.com/orders

  • api.shopconnect.com/inventory

All these APIs are deployed on the same Mule runtime.
They share the same:

  • Base HTTP Listener (port 8081)

  • Database connection (to the same PostgreSQL database)

  • Common error-handling and logging setup

Instead of defining these settings separately in each API, you can create a Domain Project (for example, Retail-Domain) that contains:

  • A shared HTTP Listener configuration on port 8081

  • A shared Database connection

  • Common global error handler

Each API then references these shared resources, ensuring everything stays consistent and easy to maintain.
If tomorrow you need to change the database password or move to a new port, you just update it once in the Domain Project — and all dependent Mule applications automatically pick up the change.

 

Implementation

Create Domain Project : 

  1. Open Anypoint Studio.

  2. Click on the File menu in the top-left corner.

  3. Select New → Mule Domain Project.

  4. Enter a name for your domain project, then click Finish.

You’ll notice that the icons for Mule Project and Mule Domain Project are different in color — this helps you distinguish between the two types of projects.

  1. Open the file mule-domain-config.xml.

    • You’ll see that it doesn’t contain a Message Flow section.

    • This means you can’t design Mule flows here — the domain project is only used for configuration purposes.

  2. On the right-hand side of the screen, the Mule Palette will appear empty.

  3. If you open the pom.xml file, you’ll notice that there are no dependencies added by default.

    • In contrast, a Mule Project automatically includes the HTTP connector dependency when created.

  4. To add the HTTP connector:

    • Click on the Manage Modules button.

    • Click Add Module (or Add).

    • Choose From Exchange.

    • Search for HTTP and add it to the project.

    • The module will be downloaded from Anypoint Exchange — this may take a few moments.

    • Once the download completes, click Finish.

  5. Next, click on the Create button and search for Listener.

    • Select HTTP Listener.

    • Configure it by providing a Name, setting the Host to localhost, and choosing any available Port.

Create mule project and reference the configuration from domain project :

  • Create a new Mule Project and name it hello-world.
  • Since we want to use the configuration from the previously created Domain Project, we need to reference it:
    • Right-click on the hello-world project and select Properties.
    • In the Properties window, select Mule Project.
    • Under the Domain section, choose the domain project you created earlier.
    • Under the Domain section, choose the domain project you created earlier.
  • Open the Mule configuration XML file (for example, hello-world.xml).
  • Drag and drop an HTTP Listener component onto the canvas.
    • You’ll notice that the HTTP Configuration is already available — this configuration comes from the domain project.
  • In the Path field, specify the endpoint path where the application will be accessible (for example, /hello).

Run the project :

  • Right-click on the Mule flow XML file and select Run Project.
  • In the Console, you’ll notice that the Domain Project is also being compiled and deployed — this happens because the Mule project depends on the domain project.
  • Once the deployment is complete, you can invoke the API using Postman (or any REST client).
  • You should receive the expected response.

⚠️ Important Note:

A Domain Project can be deployed only on a standalone Mule runtime (or on-premise environment). It will work only if the Mule applications that reference it are deployed to the same runtime instance.
If those applications are deployed to a different runtime, they will not be able to reference or use the domain project configuration, and the deployment will fail.

When it comes to CloudHub, the behavior is different.
In CloudHub, each application runs in its own isolated container, and within that container, a separate Mule runtime instance is started for that specific application.
Because of this isolation model, Domain Projects are not supported or applicable in CloudHub. Each application must contain its own configurations (such as HTTP listener, database connections, etc.) independently.

Leave a Comment