Monolithic Architecture
debt(d7/e9/b9/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints list deptrac as a tool, but automated detection is explicitly marked 'no'. The core problem — premature microservices extraction or a big ball of mud — only becomes visible through careful architectural review, not automated checks. The code_pattern describes distributed monolith symptoms that surface only during integration or deployment.
Closest to 'architectural rework' (e9). The quick_fix acknowledges that extracting services prematurely or lacking clear module boundaries requires a full rewrite to correct. Common mistakes confirm that failing to build internal module boundaries makes extraction 'impossible without a full rewrite.' This is the definition of architectural rework.
Closest to 'defines the system's shape' (b9). Applies to both web and cli contexts broadly. The architectural choice of monolith vs. microservices shapes every deployment decision, team structure, scaling strategy, and future extraction path. The common mistakes confirm that an unstructured monolith or premature microservices split affects every future change — this is a rewrite-or-live-with-it decision.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field states the canonical wrong belief explicitly: 'Monoliths are legacy architecture that should always be migrated to microservices.' Industry hype around microservices causes competent developers to assume monolith=bad, leading them to extract prematurely and create distributed monoliths — the worst of both worlds. This contradicts the actual evidence-based guidance.
Also Known As
TL;DR
Explanation
A monolith deploys all components (UI, business logic, data access) as a single application. Traditional monoliths have all concerns intertwined; a modular monolith enforces strict boundaries between modules while keeping single-process deployment. Monoliths are simpler to develop, test, and operate at early scale. The transition to microservices should be demand-driven, not speculative. Martin Fowler's MonolithFirst pattern advocates starting with a well-structured monolith, extracting services only when growth makes it necessary.
Common Misconception
Why It Matters
Common Mistakes
- Assuming microservices are always better — for most team sizes and scales, a modular monolith outperforms the operational overhead of services.
- Building an unstructured 'big ball of mud' monolith — the problem is not the deployment unit but the lack of internal modularity.
- Not building clear internal module boundaries in a monolith — impossible to extract later without a full rewrite.
- Treating 'monolith' as a slur — the pattern is appropriate for most applications and most of their lifecycle.
Code Examples
// Unstructured monolith — no internal boundaries:
// /src/UserController.php directly queries orders table
// /src/OrderController.php directly reads user settings
// Everything depends on everything — impossible to modularise later// Modular monolith — single deployable, organised by domain boundaries
// Directory structure:
// src/
// OrderManagement/
// Domain/ (entities, value objects, events)
// Application/(use cases, commands, queries)
// Infrastructure/(repositories, external APIs)
// UserManagement/
// Domain/
// Application/
// Infrastructure/
// Shared/
// Kernel/ (framework bootstrapping)
// EventBus/
// Boundaries enforced by Deptrac:
$ vendor/bin/deptrac analyse
// Fails if OrderManagement imports UserManagement domain classes directly
// Communication is via events or public application services only
// Start here before microservices — easier to refactor boundaries
// Microservices: split only when a bounded context needs independent scaling