Modular monolith
The Baxela backend is a modular monolith: a single Laravel deployment whose codebase is partitioned into bounded, self-contained modules managed with nwidart/laravel-modules.
You get microservice-style separation — each module owns its domain logic,
database tables, routes, and events — without distributed-systems overhead.
Modules live in apps/backend/Modules/, one folder per module.
Modules at a glance
| Module | Responsibility |
|---|---|
| Auth | Authentication and authorization |
| Cart | Shopping carts and cart items |
| Catalog | Products, variants, options, images, categories |
| Contact | Storefront contact-form messages and admin inbox |
| Content | CMS pages |
| Core | Shared contracts, gateways, DTOs, countries, idempotency |
| Inventory | Product stock levels |
| Media | Media uploads |
| Menu | Navigation menus and nested links |
| Notification | Email notifications (e.g. admins on contact submissions) |
| Order | Orders, order items, order addresses |
| Payment | Payments |
| Setting | System settings |
| Shipping | Shipping methods, zones, rates, shipments |
| User | Customers/users |
See Backend / Modules for the per-module reference: tables, emitted/listened events, and dependencies.
How modules interact
- Events — the primary coupling point. A module publishes domain events
(for example
OrderCreatedEvent) and other modules react through listeners. See Events. - Gateways & contracts — the Core module hosts shared interfaces,
events, gateway contracts, and DTOs. A module consumes another module's
data only through a gateway defined in Core (e.g. Shipping calls
OrderGatewayInterface::markAsShipped), never by reaching into another module's internals. - Table prefixes — each module's tables are prefixed with the module
name (
catalog_products,order_orders,shipping_rates, …), keeping the single database physically partitioned by module.
Extending the platform
Baxela is built to be extended via:
- Events & listeners — subscribe to existing domain events.
- Module overrides — replace module behavior where the module system allows it.
- Custom modules — add your own module with its own tables and events; nothing in the core assumes it exists.