Skip to content

One Deployment. Clear Modules. No Microservice Overhead.

Not every team needs microservices. The modular monolith is the pragmatic path: your PHP monolith stays a single artifact but gets structured internally into well-defined bounded contexts.

Why Monoliths Decay from the Inside.

The code lives in one repository. The domain boundaries do not. Over time, nobody knows what belongs where.

Every change breaks something else

Checkout code reads from the users table. The reporting service knows order internals. Nobody planned it. It just happened. Now every change is a minefield.

New developers take months to ramp up

No clear domain structure means no entry point. New teammates read legacy code for weeks without understanding which rules apply where. Velocity drops with every new hire.

Domain boundaries exist only in diagrams

In architecture discussions everyone agrees: orders, customers, and products are separate domains. In the codebase, this is invisible. Classes, traits, and helpers are scattered across all areas.

How Jardis Structures the Modular Monolith.

Jardis generates each bounded context as a standalone PHP package with enforced boundaries. You deploy everything together. The separation is physically enforced regardless.

DOMAIN BOUNDARIES

Hard boundaries at the filesystem level

Each bounded context becomes a standalone PHP package with its own namespace boundary. Direct access to foreign domains is structurally excluded by the package layout. Not a convention, a physical constraint.

DDD ARCHITECTURE

Complete domain structure per module

Entities, aggregates, commands, queries, domain events, and the repository pipeline: Jardis generates the full hexagonal architecture for every bounded context. Your team writes only the business logic. The structure is already there.

EVOLUTION

A stepping stone or a permanent solution

Teams that later want microservices already have cleanly scoped domains in the modular monolith. The generated API contracts and event definitions make extraction a technical step, not an architecture project.

See what three files turn into.

Three definition files in, a complete bounded context out. Browse the generated code.

E-Commerce / Sales
schema.yaml
# Database Schema — Sales Bounded Context
# This file defines the persistent storage structure.

schema:
  domain: ECommerce
  boundedContext: Sales

tables:
  order:
    columns:
      id:
        type: integer
        primary: true
        autoIncrement: true
      public_id:
        type: uuid7
        unique: true
      customer_email:
        type: string
        length: 255
      status:
        type: string
        length: 32
        default: "draft"
      total_amount:
        type: integer
      currency:
        type: string
        length: 3
        default: "EUR"
      created_at:
        type: datetime
      updated_at:
        type: datetime
        nullable: true

  order_item:
    columns:
      id:
        type: integer
        primary: true
        autoIncrement: true
      order_id:
        type: integer
        foreignKey:
          table: order
          column: id
          onDelete: cascade
      product_name:
        type: string
        length: 255
      sku:
        type: string
        length: 64
      quantity:
        type: integer
      unit_price:
        type: integer
      line_total:
        type: integer
Files
Definitions (Input)
Generated Code (Output)
BUILDER OUTPUT
80%
Domain code generatedEntities, aggregates, commands, queries, events, and the repository pipeline. Per bounded context. Your team focuses on business logic.
1
deployment artifact
3x
faster onboarding for new developers
ARCHITECTURE
0
unauthorized cross-domain accessesThe package structure makes domain boundary violations structurally impossible. No linting plugin or review discipline required.

What the Modular Monolith with Jardis Gives You.

The simplicity of a single deployment. The clarity of cleanly separated domains.

> Structure

Modules That Enforce Boundaries

No reliance on developer discipline. The package structure makes unauthorized domain access structurally impossible. Architecture rules are anchored in the filesystem.

> Independence

Teams Work in Parallel Without Conflicts

Each team owns its bounded context. Changes in one module do not affect others. Parallel development without coordination overhead.

> Pragmatism

No Microservice Complexity

No service mesh, no distributed tracing, no network latency debugging. Domain boundaries are clean, the deployment stays simple.

Ready to give your monolith clear internal structure?

Join the Waitlist

Structure costs less than chaos.

Free Trial

Try Jardis 7 Days Free

Point Jardis at your real domain. Discovery, structure, and your first platform build.

Join Waitlist
20 Discovery Runs
5 Structure Builds
1 Platform Build
All Jardis packages as open source
Jardis Base
€29per month

The complete DDD architecture with all classes and contracts. Your team ships features, not infrastructure.

Join Waitlist
Unlimited Discovery Runs
Unlimited Structure Builds
All 26 Jardis packages included
PHPStan Level 8 from day one
Jardis Pro
€180per month

The complete business logic with handlers, validation, and pipelines. What used to be a sprint is now a build.

Join Waitlist
Everything from Jardis Base
Commands, queries, and events fully implemented
Platform code in seconds instead of weeks
Additional Runs for €89 each
Enterprise

More than 20 Platform Builds per month?

Let's talk

Be there when Jardis launches.

Sign up. You'll get access as soon as we go live. Including a free trial.

100+ developers are already waiting for launch

Curious how Jardis works?

Discover Jardis

Frequently Asked Questions

Answers about the modular monolith with Jardis.

A folder structure is a convention. A modular monolith with standalone PHP packages enforces boundaries at the namespace level. Unauthorized cross-domain access is structurally excluded, not just prevented by review discipline.