Modular Monolith Folder Structure: Bootstrapper, Modules, Shared 📂

4 min readSep 2, 2024

We’re diving into the Modular Monolith Folder Structure which is is crucial for building clean, maintainable, and scalable applications.

**Modular Monolith Folder Structure: Bootstrapper, Modules, Shared**

Get Udemy Course with limited discounted coupon — .NET Backend Bootcamp: Modulith, VSA, DDD, CQRS and Outbox

Let’s break down the key components that make up this structure: Bootstrapper, Modules, and Shared. 🛠️

Here’s how to set it up:

Bootstrapper: This folder will house the API project that exposes the module APIs.
Modules: This is where the different modules of our application live, such as Catalog, Basket, Identity, and Ordering.
Shared: This folder contains common utilities and cross-cutting concerns like logging, validation, exceptions, and shared libraries for messaging and contracts.

Now let’s examine these folders one-by-one and detailed accordingly. 📝

1. Bootstrapper Folder 🚀

The Bootstrapper folder is the heart of our application. It contains the main entry point and is responsible for exposing the endpoints for our modules.

Bootstrapper.Api Project:

ASP.NET Core Web API: This project is our gateway to the application. It handles all HTTP requests.
Startup Configuration: Here, we configure services, middleware, and routing. This is also where we set up dependency injection and register our modules. 🛠️
Program.cs: The entry point of our application. This file configures and runs the web host.

By centralizing our API configuration here, we ensure a single point of entry for all HTTP requests, making it easier to manage and maintain. 📊

2. Modules Folder 📦

The Modules folder is where we define the core functionality of our application. Each module represents a distinct business domain and is organized using Domain-Driven Design (DDD) and Vertical Slice Architecture principles. Let’s break down a few modules to see what they include:

Catalog Module 📚:

Features: Subfolders for each use case, such as GetProducts, AddProduct, etc. Each subfolder contains handlers, commands, queries, and validators.
Data: Contains Entity Framework Core configurations, migrations, and the DbContext for the Catalog module.
Models: Domain models, entities, and value objects that define the core business logic.
Events: Domain events and integration events used for inter-module communication.

Basket Module 🛒:

Similar structure to the Catalog module, but tailored to basket-related functionality.
Includes Redis configurations and implementations for distributed caching.

Identity Module 🔑:

Focuses on user authentication and authorization using Keycloak.
Contains configurations for OAuth2 and OpenID Connect flows.

Ordering Module 📦:

Manages order processing and tracking.
Includes handlers for order creation, order status updates, and payment processing.
Implements the Outbox Pattern for reliable messaging between the Basket and Ordering modules.

3. Shared Folder 🌐

The Shared folder is all about reusability and reducing code duplication. It contains common utilities and cross-cutting concerns that are used by multiple modules. Here’s a breakdown:

**Shared Components: Common, Contracts and Messaging**

Shared.Common:

Utility classes, helpers, and extensions used throughout the application.
Includes logging configurations, exception handling, and other common functionalities.

Shared.Contracts:

Contracts and DTOs used for synchronous communication between modules.
Defines interfaces and abstract classes that standardize inter-module communication.

Shared.Messaging:

Configurations and implementations for asynchronous messaging using RabbitMQ and MassTransit.
Defines integration events and event handlers used for event-driven communication between modules.

Wrapping It Up 🎁

By organizing our solution into Bootstrapper, Modules, and Shared folders, we create a clean and modular codebase. This structure promotes separation of concerns, making it easier to manage dependencies and scale our application as it grows. 📈